Packaging Access 2003 Solutions

This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.

Rick Dobson

Creating a reliable setup package for Access has often been fraught with peril. Rick Dobson looks at how well the latest version of Access handles the difficult task of distributing your application.

As you consider migrating to Access 2003, one interesting question to ponder is how you'll package your solutions for easy installation. You're also probably wondering whether clients who don't have Access 2003 (or, maybe, any other Access version) can install and run your Access 2003 solutions. Microsoft has traditionally answered those kinds of questions by providing an Access runtime version (in other words, Access with no design capabilities) and a Package Wizard for creating setup routines. This is also the path taken by Access 2003.

The Package Wizard for Access 2003 creates a package for your Access solutions so users can install them just like any other Windows solutions using the Microsoft Windows Installer. This wizard optionally lets you package the Access 2003 runtime with your solution so that that your solution can run on workstations that don't have Access 2003 (or any other Access version) installed—a critical benefit in the early stages of Access 2003 adoption.

In this article I'll provide you with a brief overview of the new Package Wizard and then present examples of how to use the wizard to meet the needs of three installation scenarios. But if all you want is a quick appraisal of this feature of Access 2003, here it is: My overall impression is that I like the Access 2003 Package Wizard. That's not to say that the wizard is perfect (it's always possible to wish for more features). For example, I wish the wizard had built-in capabilities for deploying solutions over the Web (the Internet, an intranet, or an extranet). However, if you need to install Access 2003 solutions on workstations that don't have Access 2003 installed, the Package Wizard and the Access 2003 runtime is a reliable way to get the job done.

Overview of the Package Wizard

While the Access 2003 runtime ships with any version of Office 2003 that has Access 2003, the license to redistribute solutions with the Access runtime is available exclusively through the Access Developer Extensions. The Access Developer Extensions include the Package Wizard and other developer-oriented tools. The Package Wizard creates a package based on an Access 2003 solution that users can install and uninstall with the Microsoft Windows Installer.

You can only acquire the Access Developer Extensions as part of the Visual Studio Tools for the Microsoft Office System. Access developers who are adding SQL Server to their toolkits will be especially pleased that this Office 2003 edition includes the SQL Server 2000 Developer edition. You can learn more about the Visual Studio Tools for the Microsoft Office System at http://msdn.microsoft.com/vstudio/office.

To invoke the Package Wizard, you start with the Windows Start button. On a Windows XP computer, you choose Start | All Programs | Microsoft Office | Microsoft Office Access 2003 Developer Extensions | Package Wizard. This opens the wizard's welcome screen, which informs you of minimum operating system requirements for a package created with the wizard. Your target workstations for running packaged solutions need to have either Windows XP or Windows 2000 Service Pack 3.

Clicking Next on the welcome screen opens the first of seven screens that enable you to define a package template. The wizard lets you define reusable templates (templates specify settings for your setup package). Therefore, the first screen lets you specify whether you want to create a new template or select an existing one. If you select an existing template, you can use its settings to repackage a modified solution or modify the template to select new packaging options. If you think that you'll need that template again (and you probably will—most applications get released several times over their lifespan) you can save the template with a new name. Table 1 provides a brief summary of selected capabilities offered by each Package Wizard screen. Use this table along with the three packaging scenarios covered in this article to get started with the Package Wizard.

****

Table 1. A summary of the Package Wizard screens.

Screen title	Features available through screen
Package Wizard for Microsoft® Office Access 2003 Developer Extensions	Choose to create a new template or reuse a previously created template.
Database to Package	Specify Access 2003 solution to package as well as where to install the package on a target workstation.
Shortcut Properties	Specify whether users can start your package from the Start button menu, a desktop icon, or both.
Other Files or Registry Keys to Install	Designate a variety of special items that need to be installed along with your solution, such as graphic files for a splash screen or your application, as well as Registry keys.
Installer Experience	Assign a variety of required and optional items, such as an install language.
Installer Package Properties	Designate such items as the publisher, version, and contact person, along with product and support URLs.
Completing Your Installer Package	Create your package and save your package selections as either a template or a batch file.

Creating and installing an application

When you create a solution for processing by the Package Wizard, there are at least three issues that you'll need to address before you even start to create your project:

• First, it's absolutely essentially that you have a startup form for your application. This is because the Package Wizard creates packages for applications that run with the Access runtime, and the runtime version of Access 2003 has no Database window to serve as a default user interface. Your custom startup form is the opening interface for your application. Use the Access Tools, Startup menu item to set the startup options that you prefer for your packaged solution.
• Second, remember that the Access runtime makes available the Access object model, but not other object models that you may use as part of an Access solution. You can increase the likelihood of your packaged solution running successfully by avoiding references to other object models. When developing the code for a packaged solution, it may be appropriate to program with just the Access object model instead of referencing another object model that can provide a more elegant solution.
• Third, you need to decide whether to include the Access runtime in your setup package. Including the runtime will guarantee the successful execution of your solution on a target computer; omitting it means that your user must have a compatible version of Access already installed. However, including the Access runtime will also lengthen the time to create a setup package, as well as the time to install and remove your application. You should leave the Access runtime out of a package only if you know a target workstation has the Access runtime installed already in order to speed the installation of a solution within a package.

My first packaging example works with the PhoneLookup.mdb file. This simple application includes a form that lets a user look up the phone number for a shipper by highlighting a shipper name. The details of the application aren't important (if you're interested, the solution is available in the Download file for this article—at 25+MB, it's available via my site at www.programmingmsaccess.com/SmartAccessDownload/PhoneLookupImageBrowser_2003-07-24.zip). The important point is that I have a basic Access application that's ready to be packaged.

Figure 1 shows the wizard's second screen, which specifies some key pieces of information about your application's setup package and how it will be installed. For instance, it's here that you specify the Access .mdb file to be included in the package. That file typically resides on the workstation where you built your setup package. In this case, the .mdb file is in the PackageRT folder of the C:\Access11Files path.

Frequently, you'll want to install your package on your user's computer so that your application appears in the Program Files folder. You'll specify that here also. When setting this option, you should typically specify a subfolder that reflects the name of your solution. There are a variety of other root installation folder options, but some of these make it impossible to select the Access runtime as part of the package.

You also need to specify where the output of the wizard will go. The Output Options section of the screen in Figure 1 shows that this package will be placed in the Desktop folder for the Cab2000 user.

The Installer Experience screen appears in Figure 2. This lets you cache English as the Install Language setting. You don't need to cache English, but you do need to designate an install language in order to create a package. Before I was able to cache a language setting, I had to install the Access runtime on my computer. The Install Language dropdown box offers 15 European and Asian languages in addition to English. Once you cache a language, it isn't necessary to re-cache it, even when you're creating a new template for a different package.

After finishing the construction of the package, a folder with the package appears on the desktop. The folder has the .mdb filename for the solution file followed by the date of its creation. I could have used the Output Options settings to specify any other location (besides the desktop path) as the package folder (this folder includes several critical elements besides the setup.exe file). When users run the setup.exe file, they launch the Microsoft Setup Wizard and install your solution on their computers. Since I selected the check box on the screen in Figure 1 to include the Access runtime, the package directory will include the Access runtime. If necessary, you can move the package folder to a publicly accessible path—such as the Shared Documents folder on a Windows XP computer—and users can run setup.exe from that folder instead of having to move the setup files to their computers.

Figure 3 shows the result—the final Setup Wizard screen on a computer that doesn't have Access 2003 installed. If the user clicks the Start button and selects Programs, Phone Lookup will be a program option. Selecting the option would open the lookup form (there might be some optional security prompts that the user would have to step through before the application starts). The computer the package is installed on doesn't need to have any version of Access installed because my package installs its own copy of the Access 2003 runtime.

Creating a package for Web deployment

The Package Wizard doesn't offer any built-in features to support deploying a solution from a Web site. However, it's possible to adapt the process described for the Phone Lookup application to meet this goal. Users deploying your package from a Web site will almost always have a smaller bandwidth than over a local LAN or from a CD drive. Therefore, you shouldn't include the Access runtime with your package, if at all possible, whenever you anticipate the downloading of a package from a Web site. (The Access 2003 runtime requires about 30MB for itself and its installer.)

Once you know that a workstation already has the Access runtime installed, you don't need to include it with each new package. For example, you can distribute the initial version of a package via a CD. Then, you can offer clients the opportunity to download updated versions of an application from a Web site. Use the following steps for creating a package that users can download over a Web connection:

1. Create a package, but exclude the Access runtime (if at all possible).
2. Use a utility program to zip the package folder.
3. Save the zipped file for the folder to a Web site.

The process for users is:

1. On a second computer, download the zipped file from the Web site.
2. Extract the package folder from the downloaded zipped file.
3. Run the setup.exe file in the package folder.

I used these steps and posted the resulting zipped file for the package on one of my Web sites. You can evaluate the last three steps yourself, provided you have a copy of the Access runtime. The easiest way to get a copy of the runtime is probably to install the Phone Lookup application package from the accompanying Download file (again, grab it via my Web site at www.programmingmsaccess.com/SmartAccessDownload/PhoneLookupImageBrowser_2003-07-24.zip), as it includes the Access runtime. Running the setup from the Phone Lookup application package installs the Access runtime. Alternatively, if Access 2003 is installed on your computer, you already have the Access runtime. Figure 4 shows an IE browser session just before saving PhoneLookupwoRT_2003-07-24.zip from the SmartAccessDownload Web folder on my Web site (www.ProgrammingMSAccess.com).

In fact, after making the Access 2003 runtime available on a computer, users can run other installation packages for other applications (other Web-based packages) that don't include the runtime. However, the process isn't problem-free if you uninstall the application that included the runtime.

For instance, if you previously installed the accompanying Phone Lookup application, installing a version of the package from the Web that doesn't include the runtime will override the link on the Start | Programs menu. The link will now point to the LookupPhone.mdb file in the PhoneLookupwoRT folder, instead of the PhoneLookup folder.

In order to run, this second LookupPhone.mdb file in the PhoneLookupwoRT folder will require the Access runtime associated with the original Phone Lookup example. Unfortunately, removing the initial Phone Lookup application also removes the Access runtime and the PhoneLookup item from the Start | Programs menu. Furthermore, if you double-click the PhoneLookup.mdb file in the PhoneLookupwoRT folder, the file won't start. This is because the file is no longer associated with the Access runtime, since that application was removed along with the initial Phone Lookup application.

Creating a package with additional files

Some Access applications require files besides the Microsoft database file. One common scenario that requires extra files besides the .mdb file for a solution involves the use of the Image control on a form. This control takes the path and filename for an image as its Picture property. When you package a solution that includes image files, you must send the image files along with the .mdb file for your Access solution. Also, your code must automatically adjust for wherever the files are located, which may not be the same location as on the computer where you created your application.

The code behind the ShippersShipperLogos form in the PhoneLookupImageBrowser.mdb file illustrates one approach for developing file references and assigning them to the Picture property of an Image control. Figure 5 shows the form for the third record from the qryShippersShipperLogos query. This query joins an imported copy of the Shippers table from the Northwind database with another table containing ShipperID and the filename for the images corresponding to ShipperID values. I discovered the images using the Google Image Search Web site (www.google.com/imghp?hl=en&tab=wi&ie=UTF-8&oe=UTF-8&q=).

The full application in the PhoneLookupImageBrowser.mdb file contains two additional forms. The first of these is the form that lets users look up a phone number after selecting a shipper name from a combo box. The second form is a switchboard form that lets a user show either the form that displays an image for each shipper or the form that looks up shipper phone numbers. The switchboard form is the startup form for the application in the PhoneLookupImageBrowser.mdb file.

The design of the package template for this application is substantially the same as for my first example, except for settings on the Other Files or Registry Keys to Install screen (shown in Figure 6). You can see that I've specified the path and filename for three .bmp files. On the computer installing the package, these image files will reside in the same folder as the one containing the .mdb file for the solution. That folder will typically not be the Access11Files folder off the root directory of the C drive. In addition to this major change, the application has a new product name—namely, LookupBrowser, as specified on the Installer Experience screen.

After installation, the application appears on the Start | Programs menu with the name of the solution file (PhoneLookupImageBrowser). The actual PhoneLookupImageBrowser.mdb file resides in the solution folder (LookupBrowser) specified on the Database to Package screen. The solution opens to the switchboard form, and a user can click a button to show the form in Figure 5. By navigating to the third record, the same image will appear in the form as in Figure 5. This confirms that the installed application includes the image files as well as the database solution file.

Conclusion

That concludes my introduction to the Package Wizard that's part of the Access Developer Extensions for Access 2003. My goal was to give you a hands-on feel for what it's like to package Access solutions for installation with the Access 2003 runtime. You can use the files associated with this article as a starting point for learning how to use the Package Wizard. Specifically, you've seen the highlights for constructing and installing packages in three different scenarios. While the Package Wizard doesn't include built-in features to expedite the deployment of packages via the Web, you've now got step-by-step instructions and a best practice guideline for trying it. You've also seen how to deploy a solution that uses additional files along with the Access solution file (in this case, a collection of image files).

Link to www.programmingmsaccess.com/SmartAccessDownload/PhoneLookupImageBrowser_2003-07-24.zip to acquire the Download file

To find out more about Smart Access and Pinnacle Publishing, visit their website at http://www.pinpub.com/html/main.isx?sub=57

Note: This is not a Microsoft Corporation website. Microsoft is not responsible for its content.

This article is reproduced from the October 2003 issue of Smart Access. Copyright 2003, by Pinnacle Publishing, Inc., unless otherwise noted. All rights are reserved. Smart Access is an independently produced publication of Pinnacle Publishing, Inc. No part of this article may be used or reproduced in any fashion (except in brief quotations used in critical articles and reviews) without prior consent of Pinnacle Publishing, Inc. To contact Pinnacle Publishing, Inc., please call 1-800-788-1900.