Basics for Building Access 2007 Runtime-Based Solutions
Summary: Find out how to prepare your application for use with the Microsoft Office Access 2007 Runtime. (6 printed pages)
Jan Fransen, A23 Consulting
Mike Stowe, Microsoft Corporation
Applies to: Microsoft Office Access 2007, Microsoft Office Access 2007 Developer Extensions
Download the Access 2007 Runtime.
Download the Access 2007 Developer Extensions.
Introducing the Access 2007 Runtime
In some instances, developers of business applications work in environments where all the computers run the same—and the latest—version of all software. More frequently, Microsoft Office Access developers create applications that must run on computers that do not have Microsoft Office Access 2007 installed or that are running older versions of Access. For those developers, the Access 2007 Runtime is necessary.
Running in Runtime vs. Full Access 2007
The Access 2007 Runtime is basically Office Access 2007 with several key features disabled. A user who has the Access 2007 Runtime installed instead of the full version of Access can open and run an Access application, but cannot see the Navigation Pane or switch the view of any Access object to Design view.
The following features are not included as part of the Access 2007 Runtime without additional customization:
Title bar text/icon (can be specified by the database instead of by Access)
Default Office Fluent Ribbon
Quick Access Toolbar
Designers (including Filter by Form)
Visual Basic Editor
Figure 1 shows an instance of an Access application that is running using the Access Runtime. As you can see, the Access Runtime does not provide a direct user interface (UI) for opening objects because the intent is for developers to create the UI for this purpose.
Figure 1. Access Runtime instance of a sample application
Simulating the Access Runtime Environment from Full Access
Access 2007 provides two methods that you can use if you want to see how your application looks and works in an Access Runtime environment.
If you used the .accdb file format for your application, you can simulate the Access Runtime environment by changing its file name extension to .accdr or you can use the /runtime command-line switch with the full Access executable to simulate the Access Runtime environment. Create a shortcut with a target as shown in the following example.
"C:\Program Files\Microsoft Office\OFFICE12\MSACCESS.EXE" /runtime "drive:\path\file_name"
Note The line in this example might have wrapped for printing. However, no line wrapping is supported in command-line switches.
Test your application under the Access Runtime (either by using the command-line switch or by installing it with the Access Runtime on a clean computer) before you deploy the application to other users.
Creating User Interface Objects
At a minimum, every Access 2007 application destined for an Access Runtime environment must include a user interface object that enables the user to navigate through the application. This object might be a customized Navigation Pane, a custom Office Fluent Ribbon, or a startup form—that is, a form that helps the user navigate through the forms and reports that make up your application.
The Navigation Pane, new in Access 2007, is a central location from which you can view and access all database objects. The Navigation Pane replaces the Database window, which was used in earlier versions of Access. For more information about how to customize the Navigation Pane, see Create and manage custom categories and groups in the Navigation Pane.
The user interface that is provided by the Access Runtime may be sufficient for simple applications. However, most applications benefit from custom Office Fluent Ribbons and shortcut menus. For more information about how to create a custom Office Fluent Ribbon, see Customizing the Office Fluent User Interface in Access 2007.
None of the standard Help for Access is available in the Access Runtime. Often, several well-written Help topics can head off many support calls. You can use a Help authoring tool to create custom Help for your application. After you create the file, set the Help File property of each form to the name of your Help file. If your Help file includes topics for each form, you can also set the form Help Context ID property so that the Help file opens directly to the most relevant page.
Setting Startup Options
After you create the items that make up your application's user interface, you can cause most of them to load automatically at startup by using the Access Options dialog box. Use these startup options whether you are working in the Access Runtime or in full Access.
To Open the Access Options dialog box, click the Microsoft Office Button and then click Access Options. The settings that relate to your application user interface are located on the Current Database tab. Figure 2 shows the Access Options dialog box.
Figure 2. Setting application defaults in the Access Options dialog box
You can use the Access Options dialog box to specify the following:
A title for the application. This title appears instead of Microsoft Office Access in the application window.
An icon for the application. The icon appears next to the window title and in the Windows taskbar instead of the standard Access icon.
A form that opens automatically when the database is opened.
A default Office Fluent Ribbon and shortcut menu for the application. You can override these settings for a particular form by changing the corresponding form properties.
Whether the Status Bar should be displayed on startup.
The following settings are ignored when the application runs the Access Runtime and are relevant only when an application runs under full Access:
Whether the Navigation Pane should be displayed on startup.
Whether the default Office Fluent Ribbon appears.
Whether the user can make changes.
Whether special keys are enabled in Access. In full Access, these special keys provide shortcuts to display certain windows and pause executing code.
After Startup properties are set, the application from Figure 1 resembles Figure 3 at startup in Access Runtime.
Figure 3. Application provides its own UI in Access Runtime
Error Handling in VBA Code
When you run a Microsoft Visual Basic for Applications (VBA) procedure in the full version of Access and an error occurs, you see an error message such as the one shown in Figure 4.
Figure 4. Default dialog box for unhandled VBA errors
From this message box, you can decide to debug the code in the Visual Basic Editor, or you can stop the code execution and return to interactive Access.
The default error message for the same error under the Access Runtime, shown in Figure 5, is completely different. Your only option is to click OK and then exit the application completely.
Figure 5. Access Runtime uses a different default dialog box for unhandled errors
Obviously, this is not the user interface that you want to distribute to users. It is always good programming practice to handle errors that might occur in VBA code, but when users work with the application in an Access Runtime environment, such error handling becomes important. Every procedure in an application should have, at a minimum, a basic
On Error GoTo label error handler.
Helping to Protect Your Code with ACCDE Files
It is important to remember that, although an application looks different in the Access Runtime, the .accdb file itself is the same regardless of the environment under which it is running. By using the hidden Navigation Pane and designers in the Access Runtime, developers are sometimes tempted to think that it promotes security for the application. It does not. Any user who has full Access installed can open the database, exactly as the developer can, and change the design of objects or code.
Access provides a database format that helps add a measure of security to the design elements of your application: the form and report designs and code, and the code in VBA modules. This tool is the .accde file.
You can create an .accde file from an .accdb file by clicking Database Tools on the Office Fluent Ribbon, and then clicking Make ACCDE. When you create an .accde file, Access compiles all the code in the database and strips the editable version of the code from the new .accde file. This process both reduces the size of the resulting database and guarantees that no one can change the original source code. When you open an .accde file in Access, the form and report designers and the Visual Basic Editor are not available. In addition, you cannot transfer forms, reports, and modules to another database by export or import.
Note In earlier versions of Access, this was called an .mde file. If you open an older .mdb file in Access 2007, a Make MDE command appears on the Database Tools tab instead of the Make ACCDE command that appears when you are working in an Access 2007 database.
Using the Package Solution Wizard
Sometimes, distributing an Access application is as simple as copying the .accdb or .accde file to the user's drive and fixing any data links to point to the appropriate source. However, for applications that include other non-Access files such as Microsoft ActiveX controls and icons, or applications that you distribute with the Access 2007 Runtime, you want a more robust and professional setup routine. The Package Solution Wizard provides an easy way to create a Windows Installer (.msi) Setup file that guides the user step-by-step through installation.
Because the output of the Package Solution Wizard is based on Windows Installer technology, the solutions that the wizard creates can be imported by various third-party tools, such as Installshield Developer and Wise for Windows Installer. You can use the Package Solution Wizard to prepare the Access part of a larger application and integrate the result into a package created by using another third-party tool.
The Package Solution Wizard provides options that enable you to:
Include the Access 2007 Runtime as part of the installation.
Supply a title for the installation.
Provide a name for the destination folder.
Select a language for the installation.
Specify support files such as icons, a Help URL, an End-User License Agreement (EULA) in Rich Text Format, or any other files that are required for your application to run correctly.
Add information for the .msi file properties.
Specify parameters for a shortcut file that is created for your solution.
It is a good idea to save the settings of the Package Solution Wizard as a template. You can then create a VBA procedure that calls the CreateInstallPackage method, sending the names of the respective template files. The next time that you change the application and must create a deployment package, the process is as simple as running a VBA procedure.
For more information about how to use the Package Solution Wizard to create a Setup package for your application, see Deploying Access 2007 Runtime-Based Solutions.
If you are creating an application that runs in an Access Runtime environment, you must carefully consider how to provide an interface for the user. You must also consider the fact that some users may own the correct version of Access and run the application in a full Access environment. Test your application under both environments to ensure that it appropriately balances usability in the Access Runtime environment that uses code security in a full Access environment.
After you create and test your application, you can use the Package Solution Wizard that is included in the Access 2007 Developer Extensions to create a final version that you can deploy to users.
For more information about Access 2007 and the Access 2007 Runtime, see the following resources:
About the Author
Jan Fransen is a writer, trainer, and consultant specializing in Microsoft products. As a writer, Jan has developed training courseware for AppDev, contributed to books about Microsoft Office applications, written white papers for publication on MSDN, and created samples designed to help developers get up to speed quickly on new Microsoft products and features.