Developer’s Guide

In general, to upgrade your solution, you need to do the following:
1. Open the original solution database files in the current version of
FileMaker Pro.
The original solution files will be renamed “<Filename> Old” and
the converted files will keep the original name. If the solution files
use relationships or external scripts, the converted files will continue
to work together.
2. If you want, update your databases to take advantage of newer
FileMaker Pro features, such as the enhanced value lists.
3. If necessary, create scripts to import users’ existing data from the
old runtime database solution into the new, upgraded solution.
See “Importing data into an upgraded runtime database solution”
next.
4. Use the Developer Tool to bind the solution files into a new,
upgraded runtime database solution.
See “Binding your databases into a runtime database solution” on
page 6-6.
Note There may be a conflict with the icons for the runtime
application and database files if your users have an earlier version of
your runtime solution on their machines. (Your users will see the old
FileMaker 4.0 Developer Edition icons.) To avoid this, use a
different filename extension.
5. Distribute the new upgraded runtime database solution and
provide instructions for how users can upgrade their files by opening
the old files in the new runtime application and importing their data.
Importing data into an upgraded runtime
database solution
You can include scripts in the new runtime database solution files
that allow users to import records from the old runtime files.
Creating a database solution 4-17
To prepare your upgraded solution for importing data:
1. Open the original solution database files in the current version of
FileMaker Pro.
The converted filenames should be the same as the original filenames.
2. Add new features as desired to the converted solution files.
3. Place the original files in a folder named “Old Solution Files.”
4. In each of the new converted files, create an Import script that
imports all of the records from the old corresponding solution file.
5. Also, in each of the converted files, create an Open File script that
lets users open the old solution file from the new runtime application.
Users can start the new runtime application, open an old solution file,
and perform find requests to locate a subset of the records. Then they
can execute the Import script to import only those records.
Tip If you have scripts in the original solution files that help your
users reduce the found set (for example, a script that enters Find
mode and pauses), you can call that script before the Import script
step.
6. Use the Developer Tool to bind your converted files into the new
runtime database solution.
7. Test your scripts carefully.
It’s a good idea to use sample data to make sure the records are
importing properly and data is going to the correct fields. Test the
data on another machine to make sure the external scripts work.
8. Distribute the new solution files that contain the Import scripts.
9. Provide instructions telling users how to import data into the new
solution files and set appropriate time expectations. If their solution
files are large, the conversion and import process may be lengthy.
Use file size information to calculate how much disk space is
necessary for the conversion to go smoothly. Keep in mind that when
users open an old solution file from the new runtime application, the
file is copied before it’s converted. So, if a solution file is 2 MB,
users will need at least 4 MB available to convert it.