It's preferred for users to open an mde versus an mdb. When a user encounters an error in an mde, they cannot see/change the code it errors on. An mde also performs better than an mdb. You will need to have a separate backend mdb (for the tables which you link into the frontend mde - NOTE: when you create an mde out of an mdb which has linked tables, Access WILL keep the links to the backend in the mde.) Otherwise (as a pain in the butt and not at all ideal), you will need to import all the tables into the source mdb any time you need to make code changes (and stop all data entry until you have a new mde!! (or mdb))
ie..(one of different scenarios)
Backend mdb file (with data tables)
Source mdb file (i.e. frontend) which is used for code changes and to make an mde) - has linked tables to backend
User's mde file (created from the source mdb file.)
1. User requests changes (no backend table modifications) -> make changes in source mdb (frontend) -> create new (frontend) mde -> deploy new mde -> refresh tables if needed (usually no stopping of data entry).
2. User requests changes (requiring table modification) -> make design changes in backend mdb (on your backend first to test coding, then on user's backend mdb (after a backup has been made)) -> refresh linked tables in source (frontend) mdb -> create new (frontend) mde and deploy (see note below). (data entry is then "usually" only stopped for the time it takes you to make design changes on the user's backend mdb file.)
Note when using linked tables: if the user has a different folder structure, you may need to create the same folder structure on your computer or link the tables into the source mdb (or mde)/refresh the tables on their system (which you can write code to refresh the tables to a specific location).) Access doesn't know that tables linked to a backend mdb on a folder on your C: drive (that you're using for development) should be remapped to a drive such as F: when deployed on their network.
An ideal environment might be where the user let's you connect to their network and have a folder where you can work on the source frontend mdb file linking to the user's backend mdb file. You make your coding changes in the source frontend mdb (on their network in your "development" folder), create a new mde, and copy to the "deployment" folder where they are using that mde. Then you don't need to refresh the linked tables after deploying (but get in the habit of refreshing the linked tables in the source frontend mdb after making "any" backend mdb design changes.)
But there are different methods others use on how they make and deploy their changes. The above is just what I've found easiest that doesn't hold up data entry.
Last edited by pkstormy; 10-11-08 at 01:33.
Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)