User-level Access Security and Access2007 ~ LEARN MS-ACCESS TIPS AND TRICKS

Introduction.

User-level/Object-level Access Security in Access versions earlier than Access2007. All my Microsoft Access Applications were secured with User-level/Group-level Security and it is so effective when applications are shared on a Network. I have never locked the VBA Modules with the password or converted the applications into a compiled state (converting to MDE format) to protect them from tampering. User-level security provides enough resources to place a particular user where we want him to be while using the application.

If you would like to use this feature in Access2007 then you should not convert the earlier version of databases (with .mdb extension) into Access2007 (.accdb format). If you do then all the User-level security features are removed and you cannot set them back into the new version. You can continue to maintain and use the User-level security features in Access2007 if your databases are in Access2003 or earlier formats (databases with .mdb extensions).

Database Objects and Permissions

With User-level Security you can control what users can do and what they should not do. Check the following table to get some idea as to how to set permissions on each object type and what they do:

Permission	Applies to these objects	Result
Open/Run	Entire database, forms, reports, macros	Users can open or run the object, including procedures in code modules.
Open Exclusive	Entire database	Users can open a database and lock out other users.
Read Design	Tables, queries, forms, macros, code modules	Users can open the listed objects in the Design view. Note: Whenever you grant access to the data in a table or query by assigning another permission, such as Read Data or Update Data, you also grant Read Design permissions because the design must be visible to correctly present and view the data.
Modify Design	Tables, queries, forms, macros, code modules	Users can change the design of the listed objects.
Administer	The entire database, tables, queries, forms, macros, code modules	Users can assign permissions to the listed objects, even when the user or group does not own the object.
Read Data	Tables, queries	Users can read the data in a table or query. To grant user permissions to read queries, you must also give those user permissions to read the parent tables or queries. This setting implies Read Design permission, which means that users can read your table or query design in addition to the data.
Update Data	Tables, queries	Users can update the data in a table or query. Users must have permission to update the parent table or queries. This setting implies both Read Design and Read Data permissions.
Insert Data	Tables, queries	Users can insert data into a table or query. For queries, users must have permission to insert data into the parent tables or queries. This setting implies both Read Data and Read Design permissions.
Delete Data	Tables, queries	Users can delete data from a table or query. For queries, users must have permission to delete data from the parent tables or queries. This setting implies both Read Data and Read Design permissions.