Question : Securing .mdb and .mdw Files On A Network Share Location

We have user-level security setup on our frontend and backend .mdb files.

However, the backend is located on a network share location so all users can link to the database when they start their local copy of the frontend (which they also copy from a network location).

I want to know:

1) Is their is anything more I can do to stop users copying / deleting / moving the frontend and backend .mdb and .mdw files?

2) If so, what permissions would I need to set on the server?


I'm just getting 2nd opinion as in the book I've been reading, "Alison Balter's Mastering Microsoft Office Access 2003 by Alison Aalter, p.53) it says:

"An additional weakness is that the network share where the Access .mdb and .mdw files are located also needs to have read, write, and delete permissions, which means you can't prevent users from deleting or copying the .mdb and .mdw files. The only alternative is to create an n-tier application where the middle-tier objects alone have access to the physical files. However, this means that you need to write the application "unbound," since the users will no longer be directly connected to the database. When you get to that point, you'll probably be considering SQL Server or another database platform that is capable of scaling to support more users and larger volumes of data."

Answer : Securing .mdb and .mdw Files On A Network Share Location

No. As the book said, users must have read, write and delete permissions on that folder, which means any user who has permissions to access the database will also have permissions to copy the files in that folder. You could architect an app in the manner the book describes, but you're looking at a lot of work, and if you're going to do this, you'll be a lot better off moving to a true server database.

You can name the database with a non-standard name (like gwpdxg.ocx or something), and name the files and such something that would be non-ituitive. That's about as far as you can really go.