Separate an Access db into distinct data and interface files?

I've seen it done once, but didn't understand why the builder did this. What's the advanta开发者_Go百科ge, and if there is one, why is there no example of such an architecture in the literature?

I'm just looking for a best-practice approach for a small office of around <10 or so users before I begin it (an office that wants specifically to migrate to an Access db).

Thanks.

Tons of links on how and why to split your app and database into separate files. In your application each user has a local copy of the app file which is linked to the data file in some sort of shared folder.

Performance is improved. Network traffic is limited. Unique copies of temp/cached data can be maintained if needed. Backups on the data are slightly smaller. Not all users require the same features, so you can have different apps using the same data. A manager that just needs a few reports doesn't need a file with 50 forms in it.

I'd like to know what you see as the downside. Linking tables isn't that hard (If it is, get someone else to build this app.). Sending everyone an updated app file to save on their local machine isn't that hard especially in a LAN setting.

Ah, you mean two distinct Access files, one with only the system interface, and the other with the database, right?

If that's the case the answer is pretty simple.

Doing like so will provide means to update the interface without any downtime of the system operation and can help on the backup of the data.

Access files can store both the data and the user interface, if you're using the Access like this, so, any modification in the file affects every one that uses the system.

However, for the scenario that you're painting, I'd upgrade that to a SQL Server Express and an actual software developed for the company.