ACC2000: Differences Between Retail and Run-Time Microsoft Access (208730)


The information in this article applies to:

  • Microsoft Access 2000
  • Microsoft Office 2000 Developer
This article was previously published under Q208730
Moderate: Requires basic macro, coding, and interoperability skills.

This article applies to a Microsoft Access database (.mdb) and to a Microsoft Access project (.adp).

SUMMARY

When you purchase Microsoft Office 2000 Developer (MOD), your license agreement permits you to redistribute run-time versions of applications that you create to users who do not have Microsoft Access. When recipients of your application run your Setup program, a run-time license for Microsoft Access is set up on their computers.

This article summarizes the differences in the user interface between the run-time version of Microsoft Access and the full, retail version. It compares the two versions in the following areas:

  • Database Windows
  • Object Views
  • Menus
  • Toolbars
  • Unavailable Keys
  • Visual Basic for Applications
  • Error Handling
  • Help

MORE INFORMATION

When you use the "Package and Deployment" Wizard to create a run-time redistribution of your custom application, the application is not compiled into a single executable file. Instead, all of the files that Microsoft Access needs to run your database are included with your setup, and the Setup program creates a run-time version of your application by setting certain Windows registry keys.

The retail and run-time versions of Microsoft Access are identical in most respects; in fact they both use the same executable file, Msaccess.exe. However, there are some differences that you must consider when you develop your run-time application.

Database Windows

The Database and Macro windows are not visible in a run-time application. Filter By Form, Filter By Selection, and Advanced Filter windows are also hidden. The windows exist, but the run-time environment hides them. This means your application must be form-based. Users must interact with the forms that you create, and not with the underlying tables, queries, views, and stored procedures because users cannot see these objects.

Most run-time applications contain a main switchboard form, or menu, that you set as the Startup form in your database or Microsoft Access project. The switchboard form is the central point in your application from which users open other forms, run reports, and make changes to data. Because the Database window is invisible in the run-time version, if you do not include a Startup form, users see only a blank screen with a menu at the top when they start your application.

Design View

The Microsoft Access run-time environment hides the Design views of tables, queries, forms, views, stored procedures, and reports. If your application contains any buttons or toolbars that switch an object to Design view, these buttons do not work in a run-time environment.

NOTE: Hiding the Design views adds a measure of protection to your application design because it prevents users from viewing or modifying your objects.

Menus

The run-time environment removes several menus and commands from the menu bar in Microsoft Access. For example, the View, Tools, and Format menus are completely removed, and certain items are removed from the Edit, Insert, and Records menus. This prevents users from making changes to your application design.

In most cases, you create custom menus for each form. These menus control which menus and commands are available to users in the application.

Even though certain menus and commands are removed from the menu bar, you can still use the RunCommand method in your application to run commands that are on the hidden menus.

Toolbars

All of the built-in toolbars in Microsoft Access are disabled in a run-time environment. You must create your own custom toolbars for your application if you want to include them.

The run-time environment does not show and hide your custom toolbars as the context changes, so you must manipulate the toolbars in your application by using the ShowToolbar method in the OnActivate and OnDeactivate properties of your forms and reports.

Unavailable Keys

Certain keys and key combinations are unavailable in the run-time environment to prevent users from disrupting your application. The following table summarizes keys that are unavailable: 
   Keys           Description
   --------------------------------------------------------------------

   CTRL+BREAK     Stops execution of code or macro

   SHIFT          Prevents execution of an AutoExec macro and bypasses
                  database Startup properties when opening a database

   ALT+F1 (F11)   Displays the Database window

   ALT+F2 (F12)   Displays the Save As dialog box

   SHIFT+F12      Saves a database object
   (ALT+SHIFT+F2)

   CTRL+G         Displays the Debug window

   CTRL+N         Opens a new database

   CTRL+ENTER     Opens an object in Design view
   (ALT+D)

   CTRL+F11       Toggles custom and built-in menu bars

Visual Basic for Applications

The Visual Basic Editor is not included, so users cannot see your code in the run-time environment.

Error Handling

Error handling is critical in a run-time application. In a retail version of Microsoft Access, an unhandled error prompts you with an error message and in many cases enables you to view or reset the code that caused the error. In run-time Microsoft Access, if an unhandled error occurs, your application quits unexpectedly.

You can include error handling only by using Visual Basic for Applications code; macros do not provide error handling. Therefore, limit the use of macros in your run-time applications.

For more information about writing error handling code, in the Visual Basic Editor, click Microsoft Visual Basic Help on the Help menu, type error handling in the Office Assistant or the Answer Wizard, and then click Search to view the topic.

Help

If you want to provide Help for your run-time application, you must create your own Help file. Microsoft Office 2000 Developer includes the HTML Help Workshop to assist you in creating a custom Help file and the "Package and Deployment" wizard to assist you in distributing your Help file.

NOTE: The Microsoft Office 2000 Developer end-user license agreement does not permit you to distribute the Office Assistant as part of your Help system. If code in your application invokes any of the methods or properties of the Office Assistant, the code generates an error in the run-time environment.
Modification Type:MajorLast Reviewed:6/28/2004
Keywords:kbhowto kbui KB208730
©2004 Microsoft Corporation. All rights reserved.