I think he is worrying about record-locking and such.

Access, and other RDBMS are designed to be accessed by multiple users.

Depending on how you are setting this up, you probably don't need to worry much about concurrent access to the data.

Create one .mdb on the computer you elect to use as the "data-server", create your table set in that, and nothing else. allow THIS .mdb file to serve as your data-container.

Then, create an .mdb "Front-end" that will be used to access the data. This .mdb file will conatian all the forms, code, queries, report definitions your users need, but none of the tables.

Then you can either:

A. Use access "Linked tables" to create your connection, which will give you access to your table data in a familiar manner; you will have table proxies within the front end, and can manipulate them as if the tables were local.

B. Use a programmatic connection via ADODB in your code to connect at runtime on an "as-needed" basis.

C. Note that you can use code and ADODB even on the linked table set through the "CurrentProject.Connection" Property in your code.

In either case, Access is designed to manage the concurrent user access issue for you. If you do this programmatically, you will have slightly more control (and more responsibility for managing your connections and record locking).

I recommend learning and using the programmatic approach. WHile the "Linked Tables" capability is easier to implement, it also incurrs more overhead, and puts the tables (and raw data) that much closer to the user's direct access (they should really only access the data through whatever front-side strategy you have implemented, giving you control over what they can do, how and WHEN they can do it).

Using linked tables requires that you manage the linkage. If the back-end gets moved or re-named, you have to make sure to use the linked table manager to update the connection mappings.

You have to maintain these things in your code as well (if the back-end gets moved or renamed, you have to modify your connection string), but you can set the connection string up as a constand in a code module, so that you only need to change it in one place.

ALl that said, if you are using VBA code to build your forms and logic, do yourself a couple favors:

Use ADODB, not DAO as your data-access model.

Use OLEDB, NOT ODBC, as your connection model.

Hope all that helped . . .