Introduction - Access 2003.
When you develop an application, even if it is for your own use, always consider that each object you design is for someone else use. Then only we will be serious about giving a closer look at each control’s function, their strength, and drawbacks. Others may not treat each control on a Table, Form, Report, etc., as we visualize their usage, the Users may try to enter garbage into the data entry fields or may try to implement their own ideas, if they can, in the design of a Control or Form and so on.
Let us take an example of a Date-of-Birth (or an Invoice Date) data entry field on a Form. If we leave this field open to accept any date value, then it is likely that the user may make mistakes like entering a future date. To prevent such eventualities we must enable the built-in Validation checks on the value entered into the date field and warn the user about the mistake and force him to enter a valid value.
Data Field Validation Checks.
We can do this by setting the Validation Rule and Validation Text property values of the Date Field. The Validation Rule property of the date field can be set with the expression: <Date() to accept date values earlier than Today in the date-of-birth field. But, this expression is good only if we are prepared to accept date-of-birth values earlier than 100 years or more, otherwise we must set a lower bound value too, like >=(DateAdd(“yyyy”,-100, Date()) and <Date(). To warn the user about the data entry error, the Validation Text property can be set with a message text like Future date is invalid and Age Limit 100 years. This is better if you implement it on the Table itself rather than on the Form.
Preventing Changes to Important Objects.
It is equally important that Users are kept away from modifying objects like Forms, Queries, Reports, Macros, and VBA Programs. This is where we consider implementing User-level Security in Microsoft Access. The user-level security feature is available in Microsoft Access2003 or earlier versions only.
Keep Users' Freedom within Limits.
Another way of preventing users from straying out is to create Custom Menus and Custom Toolbars for the Application and disable all built-in Menus and Toolbars so that users are not able to get into object designs through the built-in Menus. If you have designed customized Menus and Toolbars, then you can disable the built-in Menus by removing the Check-marks in the Access Options.
Caution: Take a backup of the database before making the following changes otherwise you may not be able to get back into the database for making design changes yourself later.
Select Office Button - -> Access Options - -> Current Database - -> Ribbon and Toolbar Options
Remove check-marks from the following options:
- Allow Full Menus
- Allow Default Shortcut Menus
- Allow Built-in Toolbars
After removing the check-marks you must close and reopen the database. Now, the customized Menus and Toolbars you have created are only available to the User. But, unfortunately even now your database objects Forms, Reports, etc., are not safe from unauthorized changes. It is true that they cannot right-click on an object in the Navigation Pane and go into the design view, but they can if they select the VBA Module's view from the Navigation Pane, browse for a Form/Report, select it and then select View Object option.
In the VBA Navigation Pane, Forms and Reports with VBA Class Module behind them are visible to the Users. You can hide those objects by setting their Hide Option by right-clicking on the database Navigation Pane. If you don't want Users to go into the Module View, through the Navigation Pane then you may remove the check-mark from the Display Navigation Pane option along with the Menu options explained above.
Unless the User is too smart you can consider your Database Objects safe, but not safe enough from a smarter one. If someone familiar with the Keyboard Shortcuts can open the VBA Module wide open by pressing ALT+F11. You can write the rest of the story yourself from there. Even If you keep the Navigation Pane of the VBA window hidden it can be opened by clicking on the Object Browser button on the toolbar.
Since the User-level Security is not available in Access2007 and later versions, these are some of the methods available to you to implement security within an Access Database.
Once you remove the Full Menus Option it will be difficult for you to get back into the database for making changes to Forms, Reports, etc. That's why I suggest taking a backup, to be on the safe side.
Even during design time make it as a regular practice to take back-ups of the database, to save the work done so far, before starting with latest changes. If the database somehow got corrupted (or deleted by mistake) at any stage of design time you are safe from totally losing your database.
Restoring Full Menus Back.
If you want the Full menus back again we can play a small trick to get back into the database and put the check-mark back into the Allow Full Menus Option, without going through directly from the Office Button Menu.
Open the database.
Press ALT+F11 to display the VBA Window
Press CTRL+G to display the Debugging Window (Immediate Window).
Type the following command in the Debug Window and press Enter Key:
CurrentDb.Properties("AllowFullMenus").Value = TrueClose and re-open the database again.
Now, you can approach Access Options through Office Button (top left corner) and make changes to Options there.
Earlier Post Link References:
No comments:
Post a Comment
Comments subject to moderation before publishing.