Distributing applications in a compiled or uncompiled state
When distributing your Access application, you need to take several issues into consideration.
Distributing source code for your application
First and foremost, if you distribute source code and allow users to modify or add objects, you must make the users aware of the compilation issues. If your users don't fully comprehend what's happening with the application's compiled state, you can be sure that you'll receive complaints that the application is getting slower and slower over time.
Putting an application in an uncompiled state
If your application is the type that will be frequently changing its compiled state (due to creating forms and reports dynamically), or if end users will often make changes to the application's objects, or if distributed file size is an issue, you may want to consider distributing the database in a fully uncompiled state.
Follow these steps to put an application into an uncompiled state:
- Create a new database.
- Import all your application objects into the new database.
- Compact the new database.
In the "Using the decompile option" section, later in this tutorial.
Storing commonly used code in a library
After your application is finished and ready for distribution, you may want to consider placing all commonly used code into a library database (an external database referenced by an Access application database). A slight performance overhead is incurred by calling library code rather than accessing it directly in the parent application, but the library code will never be put into a decompiled state. This technique can greatly increase an application's performance and keep the performance relatively consistent over time.
The first step for using an external library is to create an external database and import all the application's code modules.
Caution: Any library procedures declared as Private are not accessible to the calling application, so carefully plan what you want to expose (declare as Public) and don't want to expose to other databases.
After you create the library database, you have to reference it in the application database (which is the database that your users will run). To create a reference, first open any module in your application in the VBA editor. With a module open in Design view, a new command - References - is available on the Tools menu. Select the References command to open the References dialog box.
When making a reference to another Access database you may need to browse for the database. After you've selected the external Access database, it shows up in the References dialog box with a selected check box to indicate that it's referenced.
To remove a reference, open the References dialog box again and deselect the referenced item by clicking its check box. After you've made all the references that you need to make, click OK.
After a database is referenced, you can call the procedures in the referenced database as if they exist in your application database. The referenced database always stays in a compiled state unless it's directly opened in Access and modified.
In this tutorial:
- Optimizing Access Applications
- Understanding Module Load on Demand
- Using the .accdb Database File Format
- Distributing .accde Files
- Understanding the Compiled State
- Application's code into a compiled state
- Distributing applications in a compiled or uncompiled state
- Creating a library reference for distributed applications
- Improving Absolute Speed
- Getting the most from your tables
- Getting the most from your queries
- Getting the most from your forms and reports
- Using bitmaps on forms and reports
- Getting the most from your modules
- Using control variables
- Eliminating dead code and unused variables
- Improving Perceived Speed
- Loading and keeping forms hidden
- Speeding up the progress meter display
- Working with Large Access Databases
- Recognizing that compiling and compacting
- Using the decompile option
- Detecting an uncompiled database and automatically recompiling