Is there a way to secure tables in ms access db from unauthorized access? I would like my users to use the forms in the db but i don't want them to see the contents of the tables. I know i can hide a table but anyone who knows just a bit about access can show the hidden tables anyway. I cna also change a name to UsysTableName but again - enabling system tables shows them all. Is there a safer way? Securing by password maybe?
+2
A:
Also in access there are users and groups, and the possibility of granting rights. You can access this functionality via tools/security/user and group permissions.
You need to create a workgroup information file in order to use this :
see : http://www.databasedev.co.uk/access_security.html
NOTE : Indeed Ms Access is in most cases a poor choice of db. But if you have to keep on using it for one reason or another, learning its security model is imperative in real world apps.
Peter
2009-09-14 08:03:52
it's not there anymore in access 2007
agnieszka
2009-09-16 15:36:49
+1
A:
For Access 2003 Understanding the role of workgroup information files in Access security at http://support.microsoft.com/kb/305542/.
For Access 2007 How to use the Workgroup Administrator utility in Access 2007 at http://support.microsoft.com/kb/918583.
In your case, I suggest moving the tables you want to secure into a different database then link to the User-Interface (front end) database. This allows you more control over security. Using a password only keeps non-users out of the database. Logged in users can still see the tables.
AMissico
2009-09-14 08:40:39
Database passwords have nothing to do with Jet User-Level Security, which is substantially more complex that simple database passwords (all that's available with ACCDB files). It's not robust enough to protect sensitive data, but it's good enough to keep out the nosy and incompetent.
David-W-Fenton
2009-09-15 00:54:12
+1
A:
One solution is to have your forms on one side (client side) and your tables on the other side (server side). Each user has only a copy of the forms, and the tables are somewhere else on the network.
Another solution is to install the runtime version of access (free to use) on user's computer. In this case the database window does not appear.
Whatever is you choice, you'll have to fully manage access to commandbars, creating you own ones (and forbidding the display of access commandbars).
If you go for the first solution, you'll be on your way to a real client/server structure, and you'll be able sooner or later to switch to SQL Server for your tables (your forms can then stay in an Access client application).
Philippe Grondier
2009-09-14 08:42:32
client server alone does not prohibit the access on the server side tables perse of course. If you set it up with linked tables as is often the case, you still have equally simple access to the tables
Peter
2009-09-14 09:00:44
You are right. I forgot this one. I was thinking of one ADODB or OLEDB connection to the 'server side', activated at runtime only, either from the code (people do that, yes!) or from some table or xml file (smarter!)
Philippe Grondier
2009-09-14 09:25:22
Storing a Jet/ACE back end on a file server is not "client/server" by any meaningful definition, as the client still needs access to the back end data file via the file system.
David-W-Fenton
2009-09-15 00:52:33
Then let's say 'front end/back end' to stick to the official terminology.
Philippe Grondier
2009-09-15 06:26:25