Developing Access Runtime Applications

Article
06/14/2014

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Developing Microsoft Access Runtime applications for distribution is similar to developing standard Microsoft® Access applications. You have great flexibility in choosing a strategy for developing your application. For example, you can create your application's tables and queries, then its forms and reports, then its macros and modules. Or you can develop your application feature by feature, creating a variety of objects as you go along. To manipulate the objects you create, you can use macros, Visual Basic for Applications code, or a combination of both.

For more information about Access Runtime applications, see:

The Development Process
Simulating the Microsoft Access Runtime Environment
Differences Between Full Microsoft Access and the Runtime Environment
The Runtime Licensing Key
Security for Your Application
Locating Localized Versions of the Access Runtime Files

The Development Process

Regardless of your strategy, there are several basic steps that you should follow when developing a Microsoft Access Runtime application for distribution.

Using full Microsoft Access, create and debug your application's tables, queries, forms, reports, macros, and modules. Forms will be a particularly important part of your run-time application.
Create help files and other documentation that will accompany your application. For more information, see Adding Help to Your Office Application.
Run your application using the /runtime command-line option, and debug any run-time environment errors. For details, see Simulating the Microsoft Access Runtime Environment.
Create your application's custom Setup program using the Packaging Wizard.
Install your application and test it on a computer that does not have Microsoft Access installed. For more information, see Testing your Setup Package.
Package your application and any printed documentation, and distribute it to your distribution sites.

Access Runtime applications have the same system requirements as Microsoft Access or Microsoft® Office.

Simulating the Microsoft Access Runtime Environment

Because some standard Microsoft Access features are hidden or disabled in the run-time environment, you should make sure your application works correctly in the run-time environment before distributing it.

If you have the Microsoft Office Developer tools installed, you can test and debug your application in Access by using the Access /runtime startup command-line option to turn off full Access features and simulate the environment in which users will run your application. Your application will look and behave as if your Microsoft Windows registry contains the run-time licensing key. However, the /runtime option does not secure your application. Any user who wants to could either remove the /runtime option from the shortcut or start Microsoft Access directly to access the design of your application's objects.

Also, for this method to work, your application must have a startup form that provides access to all the objects you want available (a main switchboard form), because you cannot display the Database window in run-time mode. For more information about the behavior of the run-time environment, see Differences Between Full Microsoft Access and the Run-Time Environment.

You can specify the /runtime command-line option by clicking Run on the Start menu or by creating a shortcut.

To create a shortcut to start your application with the /runtime option

Create a shortcut to start Microsoft Access.
Right-click the shortcut, click Properties, and then click the Shortcut tab.
In the Target box, following the path to MSAccess.exe, type the path to the database you want to open, and then type /runtime. If the path contains spaces, enclose it in quotation marks.

For example, the following command line starts Microsoft Access and then opens the Developer Applications sample application in run-time mode.
```
"C:\Program Files\Microsoft Office\Office\MSAccess.exe" "C:\Program Files\Microsoft Office\Office\Samples\Solutions.mdb" /runtime
```

Note If you are working on a network that supports universal naming convention (UNC) paths (\\ServerName\SharedFolder), you can specify the location of the database without specifying a mapped drive letter. For example, you can copy your database to a shared network folder and define the shortcut's command line to open the database from that location by using the UNC path.

Differences Between Full Microsoft Access and the Run-Time Environment

Users of your application work in an environment that combines the built-in features of Microsoft Access with the objects that you create. Unlike applications created with Microsoft® Visual Basic® or Microsoft® Visual C++®, applications created with Microsoft Access are not compiled into a single executable file. Access applications work by running your application's database file (.mdb) in the Access Runtime environment with user profiles, which are stored in the Windows registry.

While an Access application is running, it might not be apparent which elements of the environment your application supplies and which elements the run-time environment supplies. Because your application has its own look and feel, it might not even be apparent that Microsoft Access is running. Although Microsoft Access Runtime applications are identical in most respects to full Microsoft Access applications, there are some differences that can affect how you design and develop them:

The Database, Macro, and Visual Basic Environment windows are hidden, and all Design views are hidden, including the Filter windows.
Built-in toolbars are no supported, but you can add custom toolbars to your application.
Your application uses its own Help file.
Some windows, menus (including shortcut menus), and commands are hidden or disabled.
Visual Basic error handling is required. Errors that are not handled by your code will shut down the application without warning. For this reason, the use of macros is not recommended.
Certain keystrokes and key combinations are disabled.

Note If your application uses dynamic data exchange (DDE), you can specify either Microsoft Access or the application name specified by the AppDDEName user profile setting as a valid DDE application name. The run-time environment will respond to both.

The Access Runtime Licensing Key

When your application is installed on a user's computer, an entry that causes Microsoft Access to open in the run-time environment is made in the software licensing section of the Windows registry. The setup program you created with the Packaging Wizard automatically makes the necessary modifications.

When Access or your run-time application starts, it checks the licensing key to determine whether to open the database in full Access or in the run-time environment. If the application opens in the run-time environment, certain Access features are disabled and/or hidden from the user.

If no licensing key is present in the Windows registry, your run-time application will not run.

Security for Your Application

When you distribute your run-time application to users who have Microsoft Access on their computer, you should take several precautions to protect your database. The following recommendations will prevent users from making modifications to your objects and code or inadvertently causing problems with your application.

Specify the /runtime option on all command lines that you use to start your application. This forces your application to open in the run-time environment, even if a user has full Microsoft Access on their computer.
Use the Security Wizard that is provided with Access to secure all the objects in your database. To make sure that your database is completely secure, do not use the default workgroup defined by the Access workgroup information (.mdw) file that was created when you installed Access. You should create your own workgroup information file and give it a unique workgroup ID.
Use customized menus and toolbars in your application. Make sure that you do not include any toolbar buttons or menu commands that would give users access to object Design views or the Macro or Module windows.
Set the AllowBypassKey property to False to disable the SHIFT key. This prevents users from bypassing the startup properties or the AutoExec macro. To set the AllowBypassKey property by using a macro or Visual Basic, you must create the property with the CreateProperty method and append it to the Properties collection of the Database object.
Set any database startup properties that could potentially give users access to the Database window or any Design view. These properties include Use Access Special Keys (AllowSpecialKeys), Allow Viewing Code After Error (AllowBreakIntoCode), Display Database Window (ShowStartupDBWindow), and Allow Toolbar/Menu Changes (AllowToolbarChanges). To set these properties, click Startup on the Tools menu.
If your database contains Microsoft Visual Basic code, distribute it as an MDE file. Saving your database as an MDE file compiles all modules, removes all editable source code, and compacts the destination database. Your Visual Basic code will continue to run, but it cannot be viewed or edited, and the size of your database will be reduced due to the removal of the code. Additionally, memory usage is optimized, which will improve performance.