Using Full Versions Versus Runtime Versions of Access
Many people have the misconception that using the Packaging Wizard and distributing your application using the Access runtime version somehow means that the application is compiled. This is not the case at all! In fact, if you do not properly secure the database, anyone can install his own copy of Access and modify the application's data and other objects just as you can. Using the Packaging Wizard and distributing your application with the Access runtime version does not modify the database in any way. It simply gives you the license to freely distribute the engine required to run your application.Actually, the engine is not even a modified version of the Access executable! The MSACCESS.EXE file that you distribute is the same as the MSACCESS.EXE that you use to build your application. When you create installation disks for your users with the Packaging Wizard, the installation process copies the same MSACCESS.EXE file to the installation disks. So, how can there be any difference between the retail and runtime versions of Access?When the user installs your application, the installation process copies the MSACCESS.EXE to the user's machine. During this process, the installation program checks a Windows Registry licensing key to see whether the user owns a copy of Access. If the licensing key indicates that the user does not own a copy of Access, or if the key does not exist, the licensing key (which is a set of numbers and letters) is updated to indicate that the user will be using the runtime version of the product. When Access executes and the runtime licensing key is found, the product launches in runtime mode.When the runtime licensing key is found, Access behaves differently than it does when the full licensing key is found. If you are not aware of the differences, you will be quite surprised when certain aspects of your application no longer function as expected. The following is a list of the limitations of the runtime versions of the product:
- The Database window is hidden
- Design views are hidden
- Built-in toolbars are not supported
- Some menu items are not available
- Certain keys are disabled
Hidden Database Window
When users launch your application using the runtime version of Access, the Database window is not visible. It's actually there, but it is hidden because its colors are set to the same colors as the Windows background color. This means that you can interact with the Database window using code, but the users of your application will be unable to interact with the Database window directly.The fact that the Database window is hidden tends to be a double-edged sword. On the one hand, it prevents most users from modifying the objects in your application. On the other hand, it puts the responsibility on you to build a complete interface for your application. Remember that, for you as a developer, the Database window is a starting point. You must provide a different starting point and navigational tools for your users to maneuver throughout your application.
Hidden Design Views
The users of your application won't have direct access to any design views, which means that they are unable to create or modify tables, queries, forms, reports, macros, or modules. You still can get to all this functionality through code, though. You can build a wizard that enables your users to define all aspects of a query or some other object, for example, and then build the query (or other object) using ADO (ActiveX Data Objects) code. Again, this helps protect your application from novice users, but it puts the pressure on you to ensure that your application provides its users with all the functionality they need.
Built-In Toolbars Not Supported
All built-in toolbars are completely unavailable with the runtime version of Access, which means that you must design your own toolbars and attach them to your forms and reports as appropriate. This is covered in the "Adding Custom Menus and Toolbars" section of this chapter.
Unavailable Menu Items
Built-in toolbars are not supported at all when using the runtime version of Access. Menus are simply modified after the runtime key is found. Many menu items are hidden in the runtime version. These hidden menu items prevent users from making changes to your application.Although many of the menu commands are hidden from the user, they can be accessed by using the DoMenuItem command. In other words, the functionality is there, but it is simply hidden from your users.
Disabled Keys
Several keystrokes are unavailable to your users when they run your application with the runtime version of Access. Table 32.1 lists these keystrokes.
Keys | Function |
---|---|
Ctrl+Break | Halts macro and code execution |
Shift (when opening the database) | Prevents execution of the AutoExec macro and ignores Startup properties |
Alt+F1/F11 | Displays the Database window |
F12 | Displays the Save As dialog box |
Shift+F12 | Saves a database object |
Ctrl+G | Displays the Debug window |
Ctrl+F11 | Toggles between custom and built-in toolbars |