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 functions, their strength and drawbacks.  Others many 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 could, into 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.

We can do this by setting 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.

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.  User-level security feature is available in Microsoft Access2003 or earlier versions only.

Another way of preventing users from straying out is to create Custom Menus and Custom Tool bars 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 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 Sub-Routines 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 some one 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 latter 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 said to take a back-up, 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 loosing your database.

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 Office Button Menu as explained above.

  1. Open the database.
  2. Press ALT+F11 to display the VBA Window
  3. Press CTRL+G to display the Debugging Window (Immediate Window).
  4. Type the following command in the Debug window and press Enter Key:
    CurrentDb.Properties("AllowFullMenus").Value = True
  5. Close and re-open the database again. 

Now, you can approach Access Options through Office Button (top left corner) and make changes to Options there.

Technorati Tags: