Data Management

Hide Access database objects from unauthorized users

If you're working on a new Access form for your database that you don't want released to the public just yet, you can prevent others from accessing this form. Mary Ann Richardson explains to hide the icon of a form under development.

You're working on a new Access form for your database that you don't want released to the public just yet. One way you can prevent others from accessing this form is by keeping the form's icon from displaying in the database window. For example, to hide the icon of a form under development, follow these steps:

  1. Open the database window.
  2. Go to Tools | Options.
  3. Click the View tab.
  4. Clear the Hidden Objects check box under Show.
  5. Click OK.
  6. Click on Forms Under Object.
  7. Right-click the form.
  8. Select Properties.
  9. Click to select the Attributes: Hidden check box, click Apply, and then click OK.

When you're ready to work with the hidden objects, redisplay them in the database window by following these steps:

  1. Open the database window.
  2. Go to Tools | Options.
  3. Click the View tab.
  4. Click the Hidden Objects check box and then click OK. The hidden objects are now displayed as dimmed icons in the database window.
  5. Right-click the object you want to unhide and select Properties.
  6. Clear the Attributes: Hidden check box.

Caution: Because of the ease with which users can open and work with "hidden" objects, never consider this a viable method for securing your database.

Miss an Access tip?

Check out the Microsoft Access archive, and catch up on our most recent Access tips.

Help users increase productivity by automatically signing up for TechRepublic's free Microsoft Office Suite newsletter, featuring Word, Excel, and Access tips, delivered each Wednesday.

4 comments
danrev99
danrev99

I can not work on a production database that I run because of lock out issues with users that can not make changes to the databases. What I do to make changes to databases (that are not split frontend/backend) is: 1. Copy the database to my desktop. 2. Create and test the new objects. Here you can even make up data to cover different scenarios/values. 3. Save your changes to the desktop version. 4. Open your original version on the server and click import database objects. 5. Point to the desktop version 6. Find all your new objects (making sure that you DO NOT import queries as tables). This has worked time after time since I have been using Access for the last 14 years.

tlabrum
tlabrum

i always use a separate database (usually a copy of the data and a copy of the application). This allows me to develope and or create new forms, queries etc without impacting the production system. After testing on the test system i link the production data to the new system and then compile. I then copy the compiled system database to the server with the same name. This procedure also creates a backup of older versions of your application database.

access
access

The implication of this technique is that not only is the developer working in the same database as the production users, but that there is only one database rather than a split frontend/backend scenario! If indeed the database was split, the developer could have a separate copy of the frontend and actually link it to a "test" copy of the backend. When changes are done and tested, this development db becomes the new user frontend. If this were the case, there would be no need to "hide" items.

migv1
migv1

I agree. For there to be any meaningful security, users should never have direct access to database objects. All interaction must be mediated through forms and reports via the switchboard (or other custom UI).

Editor's Picks