MS-Access / Getting Started

---

Application's code into a compiled state

You have only one way to put your entire application into a compiled state: In the VBA editor window, on the Modules toolbar, choose Debug → Compile Database Name. You must have a module open to access the Debug menu. Generally, you should always use the Compile Database Name command to ensure that all the code is saved in a compiled state. Complex applications may take a long time to compile, and, in general, you may choose to compile your Access projects only before distributing to end users or before performing benchmark tests.

Note: When you choose Debug → Compile Database Name, you see the name of your project. This is the name that you used to save your database file the first time that it was created or saved. If you later rename the database file, the project name doesn't change. You can change it by choosing Tools → Properties in the module window; the database Properties dialog box contains the database name setting.

Tip: It is especially important to close your application after performing a Compile Database Name. To compile all your modules, Access needs to load every module into memory. All this code stays in memory until you close Access.

Losing the compiled state

In the past, one of the greatest roadblocks to optimizing Access applications has been the fact that an application could be uncompiled very easily. When the Access application was in an uncompiled state, Access had to constantly compile code as it was called. In fact, losing the compiled state was so easy to do in previous versions of Access that it would often happen without developers even realizing that they'd done it.

In Access 2010, only portions of code affected by certain changes are put into an uncompiled state - not the entire application. By itself, this is a tremendous improvement over previous versions of Access.

The following actions cause portions of your code to be uncompiled:

• Saving a modified form, report, control, or module. (If you don't save the modified object, your application is preserved in its previous state.)
• Adding a new form, report, control, or module, including adding new code behind a form.
• Deleting or renaming a form, report, control, or module.
• Adding or removing a reference to an object library or database by using the References command on the Tools menu.

Okay, so you think that you have a handle on code that loses its compiled state? Well, here are a couple of gotchas to consider:

• If you modify objects - such as reports or forms - at runtime through VBA code, portions of your application are put into an uncompiled state when the objects are modified. (Wizards often do this.)
• If your application creates objects like reports or forms on the fly, portions of your application are put into an uncompiled state when the objects are created. (Wizards often do this as well.)

Caution: When you change a project name (but not the filename), the entire application loses its compiled state. Because of this, you should change the project name only if absolutely necessary, and you should compile your database immediately after making the change.