Understanding the Microsoft Access Runtime Engine

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Many developers misunderstand what Access has to offer out of the box and what the Microsoft Office Developer (MOD) tools can add to the picture. They often tell me “I can’t develop applications in Access because my company refuses to buy each user a copy of Access,” or “I’m going to buy the MOD so that I can compile my applications with the MOD tools.” These are just two of the many misconceptions about exactly what the MOD tools do and don’t have to offer.

Features of the MOD

You no longer need to buy a separate product to create runtime versions of your Access applications. As a developer, you will likely buy the MOD, which includes Office Premium plus all the features from the old Office Developer Environment (ODE), plus many new components. An important feature of the MOD is a royalty-free distribution license that allows you to distribute unlimited copies of your Access application without your users having to own separate licensed copies of Access. This means that by using the MOD tools, you can create applications you distribute to your users, who can run the application with the runtime engine you distribute to them. The MOD tools also include the following:

• The Microsoft Office Object Model Guide and the Office Programmer’s Guide. In addition, numerous code samples are provided on CD-ROM.
• A Package and Deployment Wizard that helps you to create disks containing compressed files with everything you need to install and run your application.

• A host of data-bound ActiveX custom controls that can be used to enhance your application’s functionality and distributed to your users as part of your MOD license. These controls include the Enhanced FlexGrid and the Data Repeater controls.
• The Microsoft Data Engine (MSDE) is an alternative to the Jet Engine. It provides local data storage compatible with and easily upgradable to SQL Server. The MSDE is not automatically installed with Microsoft Access. To install it, run Sqlx86SetupSetupsql.exe, located on the Office 2000 CD-ROM #1.
• The Microsoft Replication Manager helps you with the replication process by letting you schedule updates between replicas, determine which objects in the database are replicated, display all the replicas in a replica set, and manage multiple replica sets.
• The COM Add-in Designer allows you to create and debug standalone COM add-ins. COM add-ins are DLLs that can be used from multiple Office applications.
• The Code Librarian provides a reusable centralized database of pre-written standard routines. This database can be easily shared across development teams.
• The Data Environment Designer allows developers to easily connect VBA code to external data sources. Using the Data Environment Designer, you can create hierarchical recordset command objects without writing any code.
• Visual Source Safe and VSS Integration provide both versioning and team management for your Access applications. After integrating Visual Source Safe into your applications, team members can check objects in and out, view the differences between versions, view the history of an object, and more.
• The String Editor is a WYSIWYG interface that allows you to quickly and easily build SQL statements. It facilitates the process of embedding SQL statements in VBA code.
• The Code Commenter automatically adds comments and headers to procedures. This is accomplished using customizable templates.
• The Error Handler is used to easily create a standard error handler for your application. It enables you to insert error handling code into your routines, using a customizable template.

Many of these utilities are covered in detail in my book, Alison Balter’s Access 2000 Development.

• The Multi-Code Import/Export tool allows you to transfer multiple code modules in and out of an application. This makes it easy for you to share code libraries.
• The Data Report Designer provides a drag-and-drop interface to report creation. This interface is available throughout the Office suite.
• The Windows API Viewer has all the declarations, constants, and type structures used with the 32-bit Windows application programming interface (API). It allows you to easily copy the function, constant, and type declarations into your code modules.

Differences Between the Standard and Runtime Versions of Access

It’s important to understand the differences between the standard and runtime versions of Access. The following differences have definite implications for the way you develop any applications you expect to run from the runtime version:

• The Database, Macro, and Module windows aren’t available in the runtime environment.
• No Design views are available in the runtime environment.
• No built-in toolbars are available in the runtime environment.
• Many windows, menus, and commands are invisible in the runtime environment. For example, the Window | Hide and Window| Unhide commands are invisible. Although these and other commands aren’t visible, their functions are generally accessible by using code.
• You must build error handling into your runtime applications. If you don’t, when an error occurs the application displays a standard Access dialog box indicating an irrecoverable error and then exits to the desktop.
• You must build your own custom help files for each runtime application.
• Some keystrokes aren’t available in the runtime application.

Some of the disabled features protect your applications. For example, the absence of the Database and Design windows means that your users can’t modify your application while running it under Access’s runtime version. Other disabled features translate into additional coding chores for you, such as the absence of command bars. If you want your application to offer toolbars, you have to build your own and then assign them to the forms and reports in your database.

Steps for Preparing an Application for Distribution

With all the features absent from the runtime version of Access, it’s not surprising you must take some special steps to prepare your application for distribution. Some of the steps are specific to running from the runtime version, but most are steps you’ll probably want to take so your application seems professional to the user. These are the steps to prepare your application for distribution with the runtime version of Access:

• Basing your application around forms
• Adding startup options to your database
• Securing the objects in your application
• Building error handling into your application
• Adding some level of custom help to your application
• Building custom command bars to be associated with your application’s forms and reports

Basing Your Application Around Forms

Your application should be based on and controlled through forms. It should generally begin with a main switchboard that lets the user get to the other components of your application; or, it can start with a core data-entry form around which the rest of the application is based. If you opt to go with an application switchboard, the main switchboard can bring the user to additional switchboards, such as a data-entry switchboard, a report switchboard, or a maintenance switchboard. You can build switchboards by using an add-in called the Switchboard Manager or by designing them as custom dialog boxes. Building a switchboard as a custom dialog box and using the Switchboard Manager to create switchboards are covered in my book. The main advantage of using the Switchboard Manager is that it lets you quickly and easily create a polished application interface. The primary advantage of custom switchboards is the flexibility and freedom they offer. An alternative to the switchboard approach is to build the application around a core data-entry form. An example is a contact management application that is based around the contacts form. All other forms and reports that make up the application are then accessed via the contacts form. This is accomplished using custom menu bars and toolbars.

Adding Start-Up Options to Your Database

Regardless of the approach that you take, you set a form as the starting point for your application by modifying the startup options for your database. Set these options by choosing Startup from the Tools menu to open the Startup dialog box. (See Figure 1.) In this dialog box, you can set startup options, such as a startup form, an application title, and an icon that appears when your application is minimized.

Figure 1 – The Startup dialog box lets you control many aspects of your application environment.

Securing Your Application

A database isn’t secure just because you’re running it from a runtime version of Access. Without security, your application can be modified by anyone with a full copy of Access, so securing your database objects is an important step in preparing your application for distribution.

In addition to security, Access 2000 offers you the ability to remove the source code from your applications. This protects your intellectual property and improves the performance of your application. The resulting database is called an MDE.

Building Error Handling Into Your Applications

If error handling isn’t built into your application and an error occurs while your user is running your application from Access’s runtime version, the user will be rudely exited out of the program. She won’t get an appropriate error message and will be left wondering what happened, so it’s essential that you add error handling to your application’s procedures. The VBA Error Handler, included with the Microsoft Office Developer (MOD), can also assist with the process of building error handling into your application.

Adding Custom Help

In most cases, you want your users to have at least some level of custom help specific to your application. You can use the ControlTip Text property of controls and the Description property of fields to add the most basic level of help to your application. The ControlTip Text property of controls is used to provide the user with a description of a control when he hovers his mouse pointer over the control. The Description property of a field, when entered, appears on the status bar when a control based on that field has the focus. If you are more ambitious, and if the scope and budget for the application warrant it, you can build a custom help file for your application. To add custom help to your application, you must build a help file; then attach parts of it to forms and controls in your application. The HTML Help Workshop, included with the Microsoft Office Developer (MOD), can assist with the process of including custom help with your application.

Building Custom Command Bars

Finally, because built-in toolbars aren’t available in the runtime version and most of the features on the standard built-in menus are disabled, you should build your own command bars associated with specific forms and reports. Creating custom command bars adds both polish and functionality to your application.

After you complete these steps, you’ll be ready for the final phase of preparing your application for distribution, which includes the following:

• Test your application by using the /Runtime switch
• Create setup disks or perform a network install with the Package and Deployment Wizard.
• Install your application on a machine that has never run a copy of either the standard or runtime version of Access.
• Test your application on the machine; make sure it runs as expected.

Before you bother running the Package and Deployment Wizard (a somewhat lengthy process), it’s best that you run your application using the /Runtime switch. This switch simulates the runtime environment, allowing you to simulate user actions under the runtime version of Access. Taking this step saves you a lot of time and energy. It will find most, if not all, of the problems associated with running under the runtime version.

After you test your application with the /Runtime switch, you’re ready to run the Package and Deployment Wizard which lets you create setup disks or perform a network install. When your users are ready to install your application, they run the installation program by using A:Setup (or the appropriate network drive and path) to get a professional-looking, familiar setup program similar to those included with most Microsoft products.

After you run the Package and Deployment Wizard, you must test your application by running the install on a machine that has never had a copy of either the standard or runtime version of Access. I suggest you use a compression utility such as WinZip to zip all the files in the test machine’s Windows System directory or back up the entire Windows directory to another directory. Install and fully test your application; make sure you experiment with every feature. When you’re done testing, delete everything but the zip file, and then unzip the zip file into the Windows System directory (so that it holds all the files it contained before your program’s installation). The whole idea is to test your application on a machine containing no Access-related files. This ensures that all the required files are included on your setup disks. After you test your application, restore the machine to its original state so that you can use it to test your next installation.

The Access Runtime Engine: Summing It Up

You have just read an overview of the differences between the full and runtime versions of Access. The process of preparing an application for distribution with the runtime version of Access is covered in detail in my book. If you plan to distribute an application with the runtime version of Access, remember which features will be available to your users; otherwise, you and your users will be in for some big surprises.

About the Author

Alison Balter is the author of Mastering Microsoft Access 2000 Development (Click to buy) a book published by Sams Publishing. This article is based on information from her book.

Alison Balter is the president of InfoTechnology Partners, Inc., a Microsoft Solutions Partner. Her training videos for Keystone Learning Systems are well-known in the Access community. Alison is a regular speaker at conferences, is an author and speaker for Advisor Media, and has also written a number of Microsoft Access books.

© copyright 2001 by Sams Publishing. All Rights Reserved.