The information in this article applies to:
- Microsoft Office 97 Developer Edition Tools
SUMMARY
Advanced: Requires expert coding, interoperability, and multiuser skills.
This article discusses techniques for upgrading run-time applications from
Microsoft Access 2.0 or 7.0 to Microsoft Access 97. It discusses these
topics:
- Upgrading an Application That Uses Split Database Design
- Upgrading an Application That Uses Single Database Design
- Upgrading a Secure Application
- Upgrading a Replicated Application
- Upgrading an Application in a Mixed Version Environment
Your situation may require procedures that are not covered in this
article; the purpose of the article is to present tips for successfully
upgrading your application, and to start you thinking about how to
implement an upgrade strategy.
Before you convert any database in Microsoft Access 97, familiarize
yourself with the conversion process. You can find sources of conversion
information in the following article in the Microsoft Knowledge Base:
ARTICLE-ID: Q160949
TITLE : ACC97: Where to Find Conversion Information for MS Access 97
MORE INFORMATION
One of the most important steps in upgrading any application is to create
an upgrade plan that addresses the issues you will encounter, such as
timing the upgrade, testing the application, and training users. A well
thought-out upgrade plan is key to successful deployment. For information
about common considerations when you install or upgrade a run-time
application, please see the following article in the Microsoft Knowledge
Base:
ARTICLE-ID: Q162584
TITLE : ADT/ODE: Developing a Plan to Deploy Run-Time Applications
The following sections present suggestions for upgrading and redistributing
run-time applications using the Microsoft Office 97 Developer Edition Tools
(ODE).
UPGRADING AN APPLICATION THAT USES SPLIT DATABASE DESIGN
This section suggests a method for upgrading your split database
application. A split database is one where you store the data (tables and
relationships) in one database on a file server computer, and the rest of
the application (queries, forms, reports, macros and modules) in another
database on each user's hard disk.
When your application uses split database design, you have the flexibility
of upgrading users over a period of time instead of all at once; you can
mix multiple versions of Microsoft Access in the application database
(front end) without having to convert the data database (back end). Because
you can mix Microsoft Access versions in the application database, this
design also lends itself well to pilot testing and stress testing of your
upgrade in a production environment.
When you are ready to upgrade a split database application, use the steps
in the following sections.
Convert and Distribute the Application Database
- Obtain a recent backup copy of both the application and data databases.
This ensures that the databases you convert will most closely emulate
the production environment.
- Convert the application database to Microsoft Access 97 and resolve any
issues that arise when you convert the database. Make necessary design
changes to the objects in the database. Leave the data database
unconverted for now.
- Test the features of the converted application database, and make
necessary changes to the database design. Also create and test your
Setup program with the ODE Setup Wizard to be sure it works correctly;
if possible, you should run the Setup program on a computer that has
your application's earlier version already installed.
- Run the ODE Setup Wizard to create the setup files for your run-time
application. Add the converted application database to your setup, and
set it as your application's main file. Add any other support files you
need to include with your setup. Do not include the data database in
these setup files.
When you create your setup with the Setup Wizard, pay careful attention
to the Overwrite Existing File box in the Add The Files screen of the
Setup Wizard. Remember that you will run this Setup program on a
computer that already has an earlier version of your application; set
the options in the Overwrite Existing File box accordingly.
- Distribute the upgraded application for pilot testing and stress
testing as determined by your upgrade plan. You may choose to conduct
these tests in a production environment.
- Distribute the upgraded application to your users. You can distribute
the application to all users at once or you can distribute it to a few
people at a time.
Convert the Data Database
- While users are upgrading to the new version of the application
database, try converting a copy of the data database in Microsoft
Access 97. Carefully document any changes you make to the design of
the tables in your database.
- After all users have upgraded to the new version of the application
database, you can convert the data database in the full version of
Microsoft Access 97. Always create a backup of the database before you
convert it. There are several ways you can convert the data database:
a. If the data database was converted easily and did not require
modification when you tested it, you can instruct an administrator
or a user to type a command line to convert the data database.
If your application uses security, the user who converts the
database must have permission in Microsoft Access to open the
database exclusively, and all users must quit the program before you
can convert the data database. Also, the user who converts the
database must have permission on the network to create a new file in
the folder on the network server that contains the data database.
Use a command line similar to the following sample to convert a data
database in Microsoft Access 97. The underscore (_) at the end of
the line is used as a line-continuation character. Remove the
underscore when you type the command, and type the entire command on
a single line:
C:\MyApp\Msaccess.exe /runtime \\MyServer\MyFolder\Data.mdb _
/convert \\MyServer\MyFolder\Data97.mdb
In this example, Data.mdb is the database you are converting and
Data97.mdb is the name of the new database after conversion. After
the data database is successfully converted, rename Data.mdb to
Data.old, and then rename Data97.mdb to Data.mdb.
b. You can convert a copy of the data database directly in a full
version of Microsoft Access 97. If you convert the database this
way, you must prevent users from changing data in your application
until you finish converting the data database. One way to ensure
that users cannot change data is to set the read-only attribute of
the data database file. Convert a copy of the data database and use
it to replace the copy on the file server. You must remove the read-
only attribute on the unconverted database before you can replace
it.
c. You can convert a copy of the data database and create setup files
for it using the ODE Setup Wizard. Obtain a copy of the database and
ensure that users will not change any data in the application while
you convert it. Then use the Setup Wizard to create setup files for
the converted data database only, and reinstall it on the network
server. Be sure to set the Overwrite Existing File box in the Add
The Files screen of the Setup Wizard to Older or Always for your
data database file so it replaces the older version when you install
it.
UPGRADING AN APPLICATION THAT USES SINGLE DATABASE DESIGN
In single database design, all database objects are stored in the same
database file. If your application uses single database design, you may
encounter some challenges timing and delivering the upgrade. In order to
preserve the existing data in the application, you must include a current
copy of the database with your setup files. That means you must establish
a cut-off date when users will stop using the application, arrange to
receive a backup copy of the live database, and then distribute the
upgrade to all users before they can begin to use the application again.
Follow these suggestions to minimize disruption to users when you are
ready to convert a database that contains all of your application's data:
- Obtain a recent backup copy of the application's database so you can
convert a database that closely matches the data you will ultimately
use.
- Convert the backup copy of the database in Microsoft Access 97 and
resolve any issues that arise when you convert the database. Make
necessary design changes to the query, form report, macro and module
objects in the database. If you make any changes to the design of your
tables, which is rarely necessary, be sure to carefully document the
changes.
- Test the features of the converted database and make more changes to
the design of the database if necessary. Also, create and test your
Setup program to be sure it works correctly; if possible, you should
test the Setup program on a computer that has your application's earlier
version already installed.
- When you are ready to distribute the upgrade, arrange for users to stop
using the application, and then obtain a backup of the most recent copy
of the production database.
- Delete the data from all the tables in the database you converted and
tested, and then append the data from the most recent backup of the
unconverted database. You can link to the tables in the unconverted
database, and then use append queries to append the data to the tables
in the converted database. When you perform this step, consider the
following:
- Referential integrity rules in the database may require you to
delete or append the table data in a particular order. You may even
have to temporarily remove some of the table relationships, and then
restore them after you have appended the data.
- If you made changes to the design of your tables in the converted
database, determine if those changes will affect the data you are
importing and take the necessary steps to import the data correctly.
When you are finished with this step, the data in the converted
database will match the data in the most recent backup. The converted
database now becomes the production database.
- Create a backup copy of the converted database as soon as you have
successfully appended all of the data.
- Run the ODE Setup Wizard to create the setup files for your run-time
application. Be sure to use the converted database with current data as
your application's main file. When you create your setup files, pay
careful attention to the Overwrite Existing File box in the Add The
Files screen of the Setup Wizard. Remember that you will run this
Setup program on a computer that already has an earlier version of your
application; set the options in the Overwrite Existing File box
accordingly.
- Use the Setup program to distribute your upgrade, and then instruct
users to begin using the application again.
UPGRADING A SECURE APPLICATION
If your run-time application uses Microsoft Access user-level security,
you must decide whether to include an upgraded workgroup information file
(System.mdw or System.mda) when you distribute your upgraded application.
The workgroup information file contains all of the user and group account
information that your application uses to implement security.
As with any Microsoft Access database, after you create the workgroup
information file in Microsoft Access 97 it will be inaccessible to users
of earlier Microsoft Access versions. If your users will be running mixed
versions of Microsoft Access, you must leave the workgroup information
file in the earliest version of Microsoft Access that any user has. For
example, as long as one user of your application is using Microsoft Access
2.0, the workgroup information file must remain a version 2.0 file.
If all users are upgrading to a Microsoft Access 97 run-time application
at the same time, the decision whether to upgrade the workgroup
information file depends on the Microsoft Access version of that file.
If your workgroup information file is a Microsoft Access 1.x or 2.0 file,
re-create the workgroup information file in Microsoft Access 97 to take
advantage of new security and performance features. For more information
about converting a workgroup information file, search the Microsoft Access
97 Help Index for "converting workgroup information files."
If your workgroup information file is a Microsoft Access 7.0 file, you do
not need to convert it when you convert your application in Microsoft
Access 97. However, you should compact the workgroup information file in
Microsoft Access 97 before you redistribute it. For more information about
how to compact the workgroup information file, search the Microsoft Access
97 Help Index for "converting databases," and then "Convert a secured
database from a previous version of Microsoft Access." Scroll to the bottom
of the topic and click the link called "Convert a Microsoft Access 95
secured database when all users are upgrading to Microsoft Access 97."
UPGRADING A REPLICATED APPLICATION
You must exercise some caution when you upgrade a replicated application.
All it takes to convert a replica database to a Microsoft Access 97
database is to synchronize with a Microsoft Access 97 Design Master. For
this reason, if one user in a replica set upgrades to Microsoft Access 97,
all users in a replica set must upgrade also.
When you want to test conversion on a replicated application, be sure to
make a copy of the Design Master database and test conversion on the copy.
That way you minimize the risk of accidentally upgrading other members in
the replica set by synchronizing with them.
For more information about a converting a replica set in Microsoft Access
97, search the Help Index for "converting replicas."
UPGRADING AN APPLICATION IN A MIXED VERSION ENVIRONMENT
Often you cannot upgrade all users to the latest version of Microsoft
Access at the same time. Sometimes the issue is timing, and you are unable
to upgrade all users at the same time. Sometimes the issue is hardware or
software, and one or more users do not have the system requirements to run
Microsoft Access 97.
Whatever the reason for the mixed environment, your application must use a
split database design if you plan to support multiple users in more than
one version of Microsoft Access at a time. With split database design, the
application database that resides on each user's hard disk can be a
Microsoft Access 2.0, 7.0, or 97 database. The data database that resides
on the network file server must remain in the earliest version of
Microsoft Access that any user has. For example, if you have only one user
with a Microsoft Access 2.0 application database, the data database must
remain a version 2.0 database.