Question : Backend / Frontend

What would be the best solution for a developing a backend frontend database in Access?

I have read up on Linked Tables, Replicias, Connection String etc, but the information didn't really provide any suggestions as the right solution for my needs.

Here are my spec ideas:
1. Multiple user (max 3)
2. Work over local or small LAN / mapped drives
3. Backend database contains "data"
4. Frontend database contains "logic"
5. Ability to change to a different backend database
6. Records will be updated in batches (although not the same record at the same time)

Also, the table structure of the backend databases will be the same. Only the filename will be different. The frontend would be used to access the databases via the same interface.

What would be the best solution given my specs? Would I need to develop any classes or modules to support backend connectivity?

Thanks in advance.




Answer : Backend / Frontend

Anytime you have >1 user, you should split the db into frontend/backend. This is pretty straightforward: your backend contains data tables only, the frontends contain everything else. All users would be provided with a copy of the frontend, and all those frontends would connect to the same backend. While some developers allow users to "share" a copy of the frontend, I prefer to provide users a copy of the frontend and install it on their desktop - this alleviates record locking issues, and is, to me at least, a "cleaner" method. It does make updating a bit more difficult, but there are plenty of ways around it. Whatever way you use, with 3 users I doubt you'll have any real trouble anyway.

When dealing with networked Access applications, be aware that Access is very dependant on fast, reliable networks. As time goes on this becomes less of an issues, but many companines are still running older 10 MBPS LANs, and Access doesn't like them very much. See here for performance tips:

http://www.granite.ab.ca/access/performancefaq.htm

Regarding relinking: Access provides the Linked Table Manager which allows you to locate and link to any Access database, but it's not the most user friendly thing available, and you have little control over what your users do. Most professional developers have in place code which does this for them, and in many cases that code is based on that found here:

MVPS.org relink code:
http://www.mvps.org/access/tables/tbl0009.htm

MVPS.org relink to different datasource (stored in tables):
http://www.mvps.org/access/tables/tbl0012.htm

I built a simple Relink class that handles all these items, but you can just as easily do this with a module, or even code-behind-form. I needed something portable that was pretty generic so that I could transfer it to diffferent projects.

The only time you'd use Replication would be for remote installations, for example if you have an office in New York and need to distribute your database to the office in Chicage. In this case you'd replicate the backend ONLY (repliation is for data, not objects) and deploy that to your remote braches. At various times, the remote braches would synchronize their data with the Hub (the "main" database, AKA the Design Master). In other words, for what you're trying to do - a locally shared database - replication would not be advisable.
Random Solutions  
 
programming4us programming4us