1
votes

So,

I've run into a bit of a problem and I'm wondering how you business users deal with this. I have Access Databases on shared drives in secured locations. It has just been set up so that only a couple of users have 'Delete' permissions (because we don't want someone to delete the database). Everyone else, has read, write, etc but NOT delete.

This works fine, but I've noticed that the Record-Locking-Information file is not deleted after the regular users log off the database (I'm sure due to the 'no-delete' permissions for the folder).

What solutions to this problem have you all implemented?

1
Is it a problem? It is not essential that the file is deleted. - Fionnuala
I guess that's part of my question. Is there a problem that this file persists even when no one is using the database? And it will never be deleted unless an administrator manually deletes it. EDIT: Also, when I'm developing it, I generally check for the Record Locking Information file first to determine whether it's in use or not. - Scotch

1 Answers

1
votes

Many have suggested that you must give FULL permissions to users, but this is not true. You need only give them MODIFY permissions -- you can deny them DELETE permission, which is a good idea, as it prohibits the users from "accidentally" deleting your data file.

It is true that for a user with DELETE permissions, the LDB file will be deleted on exit when that user is the last user exiting the database. But it is not required that the LDB file be deleted -- indeed, in Access 2 and before, the LDB files were not deleted on exit, but just left there hanging around. This generally has no downside, but occasionally the LDB file gets corrupted and causes problems and really does need to be deleted and recreated afresh.

What I do is have two classes of database users (as defined in custom NT security groups specific to my Access application(s)) -- DBAdmins and everyone else. The DBAdmins have FULL permissions, everybody else only CHANGE. The result is that any time a DBAdmin exits as the final user, the LDB is deleted. This setup works really well, and I've been using it for well over a decade.

-- David W Fenton