Part IV: Professional Database Development
848
- Specify a name, drive, and folder for the database.
Don’t try to save the .accde file with the same filename (including the filename exten-
sion) as the original database.
Caution
Don’t delete or overwrite your original database! You can’t convert an .accde file to a normal database, and
you can’t edit any objects in an .accde file. If you delete or otherwise lose your original database, you’ll
never again be able to access any of the objects in the design environment.
Note
You can create an .accde file only if you first convert the database into the Access .accdb format. If the file
is in an Access 2002–2003 format, you can create an .mde file — the Access 2002–2003 equivalent to an
.accde file.
Understanding the Compiled State
Understanding how Access performs Compile on Demand is critical to achieving maximum perfor-
mance from your Access application. However, it’s also paramount that you understand what com-
pilation is and what it means for an application to be in a compiled state.
Access has two types of code — code that you write and code that Access understands and exe-
cutes. Before a VBA procedure is executed, the code must be run through a compiler to generate
code in a form that Access understands — called compiled code.
Access lacks a true compiler and, instead, uses partially compiled code and an interpreter. A true
compiler converts source code to machine-level instructions, which are executed by your comput-
er’s CPU. Access converts your source code to an intermediate state that it can rapidly interpret
and execute. The code in the converted form (compiled code) is known as being in a compiled state.
If a procedure is called that isn’t in a compiled state, the procedure must be compiled and the
compiled code passed to the interpreter for execution. In reality, as previously stated, this doesn’t
happen at the procedure level, but at the module level. When you call a procedure, the module
containing the procedure and all modules that have procedures referenced by the called procedure
are loaded and compiled. You can manually compile your code, or you can let Access compile it
for you on the fly. It takes time to compile the code, however, so the performance of your applica-
tion suffers if you let Access compile it on the fly.
In addition to the time required for Access to compile your code at runtime, uncompiled programs
use considerably more memory than compiled code does. When your application is completely
compiled, only the compiled code is loaded into memory when a procedure is called. If you run an
application that is in a decompiled state, Access loads the decompiled code and generates the com-
piled code as needed. Access doesn’t unload the decompiled code as it compiles, so you’re left with
two versions of the same code in memory.