About securing Visual Basic for Applications code in Access databases (MDB)

In a Microsoft Access project (.adp) file and a Microsoft Access database (.mdb) file, you can help protect all standard modules and class modules (such as code behind forms and reports) by employing passwords for VBA code, which 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 employing security measures for your VBA code in this manner doesn't prevent you or other users from running existing VBA code.

Saving your Microsoft Access database as an MDE file compiles all modules, removes all editable source code, and compacts the destination database. Your Visual Basic code will continue to run, but it cannot be viewed or edited. Your Access database will continue to function normally— -you can still update data and run reports— -and the size of the database will be reduced due to the removal of the code. Memory usage is optimized, which will improve performance.

Saving your Access database as an MDE file prevents the following actions:

• Viewing, modifying, or creating forms, reports, or modules in Design view.
• Adding, deleting, or changing references to object libraries or databases.
• Changing code using the properties or methods of the Microsoft Access or VBA Object models— an MDE file contains no source code.
• Importing or exporting forms, reports, or modules. However, tables, queries, data access pages, and macros can be imported from or exported to non-MDE databases.

In a Microsoft Access 2000 or later database, standard modules and class modules (such as code behind forms and reports) no longer employ user-level security, as they did in previous versions. However, forms and reports still make use of user-level security. This means that modules and forms and reports employ 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.