Microsoft Office 2000 Developer

Targeting the Access Run-Time

See Also

Developing Microsoft Access Run-Time 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 using the Access Run-Time in your applications, see:

• The Development Process
  
  
• Simulating the Microsoft Access Run-Time Environment
  
  
• Differences Between Full Microsoft Access and the Run-Time Environment
  
  
• The Run-Time Licensing Key and Microsoft Access
  
  
• Securing Your Application If Users Have Full Microsoft Access
  
  
• Locating the Access Run-Time

The Development Process

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

1. 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.

   If you need to secure any objects or provide security features in your application, follow the guidelines described in Chapter 18, "Securing Access Databases" in the Microsoft Office 2000/Visual Basic Programmer's Guide.

2. Create Help files and other documentation that will accompany your application. For more information, see Adding Help to Your Application and Chapter 13, "Adding Help to Your Custom Solution" in the Microsoft Office 2000/Visual Basic Programmer's Guide.
   
   
3. Run your application using the /runtime command-line option, and debug any run-time environment errors (requires installation of Microsoft Office 2000 Developer). For more information, see Simulating the Microsoft Access Run-Time Environment.
   
   
4. Create your application's custom Setup program and disks using the Package and Deployment Wizard. For information about including the Access Run-Time in the package, see Creating Dependency Files.
   
   
5. Install your application and test it on a machine that does not have Microsoft Access installed. For more information, see Testing your Setup Program.
   
   
6. Package your application and any printed documentation, and distribute it to your distribution sites.

Run-time applications have the same system requirements as Microsoft Access or Microsoft Office.

Simulating the Microsoft Access Run-Time 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 2000 Developer tools installed, you can test and debug your application in Microsoft Access by using the Microsoft Access /runtime startup command-line option to turn off full Microsoft Access features and simulate the environment in which users will run your application. Your application will look and behave as if your 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.

Tip   If Microsoft Access is installed on a user's machine, you can test your run-time application by copying the file mso9rt.dll to the user's ..\Program Files\Common Files\Microsoft Shared\VBA\VBA6 folder.

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 can't 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

1. Create a shortcut to start Microsoft Access.
   
   
2. Right-click the shortcut, click Properties, and then click the Shortcut tab.
   
   
3. 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 Solutions 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 aren't compiled into a single executable file. Microsoft Access applications work by running your application’s database file (.mdb) in the Microsoft Access Run-Time environment with user profiles, which are stored in the Windows registry.

While a Microsoft Access application is running, it may 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 may not even be apparent that Microsoft Access is running. Although Microsoft Access Run-Time 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 aren't 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 Run-Time Licensing Key and Microsoft Access

When your application is installed on a user's machine, 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 Package and Deployment Wizard automatically makes the necessary modifications.

When Microsoft Access or your run-time application starts, it checks the licensing key to determine whether to open the database in full Microsoft Access or in the run-time environment. If the application opens in the run-time environment, certain Microsoft 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.

Securing Your Application If Users Have Full Microsoft Access

When you distribute your run-time application to users who have Microsoft Access 2000 on their machines, 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 machine.
  
  
• Use the Security Wizard that is provided with Microsoft Access to secure all the objects in your database. To make sure that your database is completely secure, don't use the default workgroup defined by the Microsoft Access workgroup information (.mdw) file that was created when you installed Microsoft 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 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.

For more information, see "Securing Office Solutions" in the Microsoft Office 2000/Visual Basic Programmer's Guide. For more information about MDE files, see "About MDE Files" in the online documentation for Microsoft Access.

Locating the Access Run-Time

When you use the Package and Deployment Wizard to include the Access Run-Time in your application, a message prompts you to locate the Access Run-Time files.

The Access Run-Time is not installed to your machine as part of the Microsoft Office 2000 Developer setup. Instead, you can find it on the Microsoft Office 2000 Developer CD in the Access Runtime folder. To avoid having to use the CD each time you package the Access Run-Time, you can copy the necessary files to your machine.

To copy the Access Run-Time to your machine

1. On the Microsoft Office 2000 Developer CD, located in the Access Runtime folder.
   
   
2. Copy the contents of the Access Runtime folder to the following location on your machine:

   ..\Program Files\Microsoft Office\ODETools\V9\Runtime