If you do a split or not, a cardinal rule with an "ongoing" DB is to always keep extra copies. Keep GOOD backups. Another one of those copies will be your "working copy" that you use for future upgrades, new features, fixes, etc. IF you have a split DB, it is not uncommon to take a working copy of the back-end file and use that for your working copy for testing. (See detailed suggestions below.) Besides the working copy, you ALWAYS make backup copies of anything you are about to replace so that if things go
you can quickly revert - and later, you can look at the backup if you were unsure about what you did. An important fact to remember: Access does what it does to link to a shared back-end using file names. A file might have some complex internal identifier, but Access doesn't use that. It uses the full file specification: DEV:/path/name.type - and that's all.
In the case of a non-split database with "live" data where you are getting ready to share, you need to split right away, perhaps before you share, due to issues that arise in conflicting file locking, which can lead to database corruption VERY quickly. But you said you split it, so you won't run into that particular problem. I mentioned it so you would understand that a split DB is a GOOD choice when sharing the app.
In the specific case where you have a split DB and the back-end is being shared, the issue of updating the FE is multi-step, but not that tedious.
1. Make a copy of the front-end that everyone is using. Using the the external data tools from the ribbon, point this copy of the FE file to the copy of the BE file in the working area. (IF you don't have a BE copy in the working area, make one NOW, before you do any work on the FE.) The "working area" FE copy always points to the working area copy of the back-end file.
2. Modify the FE copy with your upgrades & fixes. When the working copy is as you want it, copy that file to a separate staging area. You do this so that the "working" copy of the FE continues to point to the working copy of the BE file.
3. Using the external data tools from the ribbon on the staging-area copy, update this FE to point to the shared "live" back-end file.
4. NOW you can create the .MDE/.ACCDE file to be distributed in the staging area.
5. Make a backup copy of the FE file that is about to become obsolete.
6. Place the new FE file in the folder where your user will copy it or from which you will distribute it.
7. (A non-step) The BE file never has to be touched as long as you have made no structural changes. You don't care whether there were data changes while you were working anyway. The DB doesn't have to "go down."
Now, it IS possible that you want to update something structural in the BE file. That is more difficult because you have live data to preserve in that back-end file. So you set up a time when your users know the DB will be out of service. When that time comes, verify that you have no lock files open (.LDB or .LACCDB) in the folder where the BE resides. If necessary, visit the users while carrying an ugly medieval weapon to persuade them to drop out of the DB. (Some users are unusually insistent that they really need to keep working...)
1. When you know that all users are out of the DB, copy that BE file immediately to your working area. Then RENAME the shared copy of the BE file in the shared area. Since Access works by file names, this effectively turns off the DB hard. In this context, your emergency backup is the renamed copy.
2. With the working BE in the work area, open it directly and make your structural changes. IF you ALSO need to update the front-end file, do these changes simultaneously, working from the work area.
3. Whether or not there were FE changes, using the working FE copy (in the work area) and the external data tools from the ribbon to direct the test copy to the copy of the BE file. Test it. IF the FE was also changed, you would have also updated the FE file, so that is the version for testing.
4. When all of it works as expected, finalize any actions in the updated BE file. IF the FE was also modified, finalize it. However, there is a minor wrinkle in this case since you have to update the links from FE to BE before you create the .MDE/.ACCDE file.
5. Move this copy of the BE to the area where it normally resides under the name that the DB expects to see. Note that at the moment the file with the right name for the BE file appears in that folder, the DB is open again. THEN redirect the links in the FE and make the .MDE/.ACCDE file. Move that new FE file to the distribution folder.
6. Move the BE copy you renamed earlier to the folder you use for backups and rename it according to your backup standards.
Seems like a lot, but I can tell you that this method worked for me in a fairly exacting environment - the U.S. Navy - on a "For Official Use Only" site.
