I don’t think it’s a split db. (Yikes) we will revisit this morning.
OK, I don't know your expertise level so if my comments are a little bit insulting, it's not my intention - but your comments make me think I recognize you - in the mirror from my own past about 25 years ago. When I took over someone else's mess of a DB, I became the
de facto guru for Access and MS Office-based VBA. (Can you say "sink or swim"?) If so, you are either not aware of the issue or are still working on it.
There are two major architectures in the world of "native" Access databases. There is the "monolithic" application and there is the "split" application. In the ribbon for Database Tools you can find the splitter. What that does is take the monolithic DB file, which contains everything there is to know about your app, and splits it into two files. The files become the front-end and back-end, or FE and BE in our most common usage. You copy the FE file once for each user and give each one a copy. Then you put the BE file in a common area shared over the network. The BE will contain all tables and nothing else. The FE will contain queries, forms, reports, macros, modules... and links to the BE file for the tables.
You do this split for the reason of file locking, which is the Windows mechanism that keeps two programs from changing a file at the same time, neither one being aware of the other's actions. With improper sharing, this leads to "destructive interference" (the tech term) or "left hand doesn't know what the right hand is doing" (colloquially). This interference in a monolithic DB ALSO leads to that most dreaded problem, a corrupted DB file for which you get a message about the app file being in an unrecognized format or unknown format or something similar. And it is odds-off that you would ever open that file again.
When sharing properly, the monolithic file has been split and each user has a private copy of the FE. Since it is a private copy, even though it has file locking just like any other Windows file, it is not being shared - so there will be no lock collisions in the FE file. Nothing is there to collide. You have to then make that copy of the FE point to the place where you put the BE file. This is in the ribbon for External Data, and while it might be a little bit tedious, it is a one-and-done action until time for an updated FE file, which happens on YOUR schedule. And all you do is tell folks, "go to \xyz\FE\" folder and replace your current FE file by deleting your current FE and copying the new FE in its place. You will learn that the last act of preparing a new FE is to go in and re-point it to the BE file.
The BE file WILL have to be tended a bit more carefully. The most important factors are that (a) every user has MODIFY rights on the shared folder and (b) every file to be shared from that folder has MODIFY rights. You DON'T need (or want, usually) FULL CONTROL. The reason you need MODIFY is more complex. For now, understand that it implies about a dozen specific actions, which includes the creation and deletion of what we call the "lock file" - of type .LACCDB (or .LACCDE if you compiled the DB to produce a .ACCDE file.) Access will open a lock file in two places. First, where your user has the FE file, there will be a lock file - but because it is local, it is ALSO not shared and cannot run into "lock collisions." Second, where the BE file is located, there will be another lock file. This is the one that prevents two app users from stepping on each other's toes.
A question is in order: Do you have a domain environment in which you can create domain-wide group identifiers? I'll defer the long explanation unless you actually need it, but having a domain-level group identifier would make it easier for you to add file-access permissions for new users. Without that, you have to add each new user to the rights list for the folder & files. A properly distributed FE file, though, is a local copy and so will be owned by each user - particularly if THEY do the actual copy to a convenient local folder on their PC. So no file-lock conflicts.
Now, HERE is a big thing to watch for. You can NEVER allows any user to share the FE file in the folder where you keep it for distribution. THAT is where destructive interference will eat your socks. Users must ALWAYS use the app via the local copy of the FE file. The BE file sharing is managed by Access itself. If you WERE sharing FE files (specifically meaning two people opening the same physical file at the same time), Access would TRY to keep things straight, but it can't if two people open the same form at the same time from the same physical file. I can explain that, too, but this is enough for you to soak in at a single sitting.
