About protecting Visual Basic for Applications code

About protecting Visual Basic for Applications code

This topic provides reference information about:

Protecting Visual Basic for Applications (VBA) code

Modules, forms, reports, and user-level security

Protecting Visual Basic for Applications (VBA) code

In a Microsoft Access project and Microsoft Access database, you can protect all modules, and modules behind forms and reports by protecting VBA code with a password that you and other users must enter to view or edit VBA code in the Visual Basic Editor. Once you set a password, you enter this password once per session. The password is required not only for viewing and editing, but also for cutting, copying, pasting, exporting, and deleting any module. Note, however, that protecting your VBA code in this manner doesn't prevent you or other users from running existing VBA code.

Return to top

Modules, forms, reports, and user-level security

In a Microsoft Access 2000 database, modules and modules behind forms and reports are no longer secured by user-level security, as they were in previous versions. However, forms and reports are still secured by user-level security. This means that modules, and forms and reports are protected by two different security mechanisms.

For example, assuming you have the appropriate permissions, you can add a control to a form, but if the VBA project is locked for viewing and protected with a password, and you don't know the password, you can't view or edit the module behind the form. Conversely, you can be restricted from designing a form or report through user-level security by not having Modify Design permission on the object, but if you know the VBA project password, you can access the module behind the form or report.

There is an exception to this. Even if you have Modify Design permission on a form or report, you cannot delete the form or report, or set the HasModule property to No, because this action deletes the module behind the form or report.

Return to top