There is still a way, though you will have a hard time taking things away from folks who will probably be indignant about losing privileges. But this works. I know because I've got a bunch of administrators as the users of my Access database, too.
First, institute workgroup security. Create an empty workgroup. Put it in the same directory as the shared database. Give it a name other than SYSTEM.MDW - perhaps something similar but not identical to the database name. Don't join that workgroup quite yet, though. Give everyone an account. Do NOT give them individual privileges. Don't give yourself individual privileges either. Just let the accounts exist as members of the Users group, which is the default case.
Next, create a couple of NEW group descriptors in the database. You will already have two: Users and Admins. Basically, you will NEVER again use those two, they are about to become totally useless. You will need two more groups.
Group 1 is the REAL administrative group. This group has EVERY POSSIBLE PRIVILEGE on EVERY OBJECT IN THE LIST. Plus every privilege on the <New xxxx> object that is the top of every object list in the permissions dialog.
Group 2 is the powerful but not absolute group that represents your other users. TAKE AWAY "OPEN EXCLUSIVE" from this group. Also step through the available privileges to see whether there are structural things you DON'T want them to do for your critical structures. Like, perhaps, no rights to delete objects that they didn't themselves create.
Step through the existing DB objects to assure that they are owned by YOU and not by Admin account. (Or owned by whatever name you chose to be the new admin account.)
Put your newly created account into the first group (the one with ALL privileges), whatever you called it. Now immediately exit the database. Join the new workgroup. Now re-enter the database under the name you chose for your personal account.
COMPLETE ALL OF THE ABOVE BEFORE YOU ATTEMPT THE FOLLOWING STEPS. (Otherwise, you are in the situation of the cartoon character who sits on a limb in order to saw it off...)
Now edit the Users group so that it is READ-ONLY for everything. Maybe even take away "view design" from Users if you want to be really picky. Do the same for the Admins group. Assure that you also take away OPEN EXCLUSIVE from the Admins group.
Now tell everyone that if they don't join the workgroup, they don't get into the database. They'll grumble, but this should help the stability of the DB and it should also make them more aware of how often they were stepping on each other's toes.
Now I'll tell you why you did what I said you should do:
By default, if you don't join a workgroup, you come in as user Admin (no "s" on the end), who is a member of the Admins (with an "s") group. Which has OPEN EXCLUSIVE and a bunch of other rights. But if you re-define a new Admins group and put yourself in that group, you can retain control when you take away the rights from the others.
The use of groups to control security rights makes it easier in the case where lots of users have the same rights. You just assign them membership in the group rather than giving each one his or her own individual rights. That way, the job comes closer to being reasonably manageable.
I know that setting up WorkGroup security is a pain in the toches but it should help with at least SOME of the problems you are seeing. Maybe not all. But I'm guessing that ANY help is better than none, given the frequency of database backup that you described.
