User-level Access Security and Access2007
User-level/Object-level Access Security concepts remains with 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 password or converted the applications into 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 in 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).
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 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 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||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 users permissions to read queries, you must also give those users 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 permissions 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 permissions 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 permissions to delete data from the parent tables or queries. This setting implies both Read Data and Read Design permissions.|
- Create your own Color Pallette
- Colors 24 bits and Binary Conversion
- Hexadecimal Numbering System
- Octal Numbering System
- Learn Binary Numbering System-2