ACC97: Differences Between Retail and Run-Time Microsoft Access

ID: Q162521

The information in this article applies to:

SUMMARY

Moderate: Requires basic macro, coding, and interoperability skills.

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

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


MORE INFORMATION

When you use the Setup 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 you must consider when you develop your run-time application.

Database Windows

The Database, Macro, and Module 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 interact with the forms you create and not with the underlying tables and queries, which they cannot see.

Most run-time applications contain a main switchboard form, or menu, that you set as the Startup form in your database. 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 run-time, when users start your application they only see a blank screen with a menu at the top if you do not include a Startup form.

Views

The Microsoft Access run-time environment hides the Design views of Tables, Queries, Forms, and Reports. If your application contains any buttons or toolbars that switch an object to Design view, they will not work in a run-time environment.

This feature adds a measure of protection to your application design, and 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 of your forms that control what menus and commands are available to users of your 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 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

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, an unhandled error shuts down your application.

Error handling can only be accomplished with Visual Basic for Applications code; macros do not provide error handling. Therefore, limit the use of macros in your run-time applications.

Help

If you want to provide Help for your run-time application, you must create your own Help file, and then set the AppHelpFile key in the Windows Registry. Microsoft Office 97 Developer Edition includes a Help Workshop to assist you in creating custom Help files, and the Setup Wizard to assist you in setting the AppHelpFile registry key when you create your Setup files.

Note that the ODE 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 methods or properties of the Office Assistant, it will generate an error in a run-time environment.


REFERENCES

For more information about the topics presented in this article, search the Help Index for "run-time environment, differences between Microsoft Access and."

Additional query words: ODE ADT RT stand alone full 


Keywords          : kbui UifDbwin UifKeybd UifMenub 
Version           : 97
Platform          : WINDOWS 
Issue type        : kbinfo

Last Reviewed: April 14, 1999