20. Converting Systems from Previous Versions of FileMaker Pro

Updating and Upgrading FileMaker Software

FileMaker—like almost every software developer in the world—issues updates and upgrades to its software periodically. Typically, updates are downloadable, and, with rare exceptions, they’re free. On the other hand, upgrades generally are priced.

Updates and upgrades are sometimes issued to correct bugs and tighten security lapses that have been discovered. More often, they implement new features and new ways of doing things. Most of the time this is due to the hard work and imagination of the developers at FileMaker, Inc., but it also is due to requests from users.

Use the forums at www.filemaker.com/support/contact.html to ask questions and make suggestions. FileMaker monitors them to see where people are having problems and whether something can be done to make life easier for the users. Find FileMaker conversion documentation at www.filemaker.com/r/conver.

Because updates contain fewer changes than upgrades, they generally cause few, if any, problems. However, whenever you change anything at all in your computing environment, you should always back up the relevant files so that if anything does go wrong, you can revert to the previous version. Many people rely on full system backups for this purpose: It can be much faster to just back up everything than to determine what might be affected.

Migrating to New FileMaker File Formats

As you have seen in this book, your FileMaker environment frequently consists of a variety of FileMaker files and, often, a variety of FileMaker software products. You might use FileMaker Pro for your daily work, but you might have a copy of FileMaker Pro Advanced that you use when designing new databases. You might use FileMaker Go on your iPhone or iPad; you might access databases that you have downloaded or sent to the iOS device, or you might access them from shared files that you have hosted on FileMaker Pro.

You also might use FileMaker Pro or FileMaker Go to access files that are shared through FileMaker Server. Furthermore, you might have deployed Custom Web Publishing (CWP) and Instant Web Publishing (IWP) solutions with FileMaker Pro or FileMaker Server. You (or others) may access CWP and IWP solutions via a browser.

As a general rule, FileMaker maintains interoperability among its products so that you don’t have to worry about upgrading or updating all of your FileMaker products at the same time. However, this is not always the case. Occasionally, it is necessary for FileMaker to change the formats of database files in order to implement new functionality or accommodate new features of hardware and environmental software. At such times, you must migrate your FileMaker files to the new format. The change in format is indicated by a change in the extension for FileMaker files.

This doesn’t happen very often. Here are the major extensions that have been used:

• .fmp12—The FileMaker 12 products (FileMaker Pro 12, FileMaker Server 12, and FileMaker Go 12) introduced this file format in 2012. Files are automatically converted from the prior .fmp format when you open them for the first time.

• .fp7—This format was introduced with FileMaker Pro 7 in 2004. Files were automatically converted from previous file formats using the .fp3, .fp5, and .fpj extensions, which date back to FileMaker 3 in 1995.

Because the .fp7 extension has been in use for nearly a decade (at the time this book was written), the focus in this chapter is on migration from that format to the new FileMaker 12 format. Fortunately, the issues involved in converting from .fp7 to .fmp12 are relatively few. This chapter explores the major ones.

Planning the Conversion

Unless you are working with a single-file solution that is used for noncritical work, you should plan for the conversion. The first step in planning a conversion is to decide what you will do. Your choices range from totally rewriting the solution to doing the smallest amount of work necessary to get everything up and running in the new environment. For an old solution with years and years of edits (which often do not use scripting features such as parameters that make your life easier), this can be an opportunity to start over or at least to clean up the code.

Beyond code cleanups, think about whether it is time to add functionality to your solution. One major area to think about is making your solution accessible to mobile devices and FileMaker Go if it is not already ready for them. You do not have to go all the way to mobile implementation; you can begin to pave the way during your conversion. With even just a few of these steps, you will be making the eventual mobile implementation easier.

Here are some steps you might consider with regard to layouts and layout names:

• Look at the strategy used in the Starter Solutions where you have parallel layouts for iPhone, iPad, and desktop. You can begin to implement that structure in your converted solution by naming layouts appropriately.

• You can plan for an incremental evolution if you have a solution that does not run on mobile devices. In that case, every layout is designed for the desktop.

• Use the structure of layouts in the Starter Solutions by creating a Desktop layout folder and putting the existing layouts in it.

• Rename all the existing layouts with a prefix such as Desktop.

• Any Go To Layout script steps will still work because they use internal layout ID numbers rather than the layout names, unless you explicitly calculate the layout name. This will position you to add mobile devices easily in the future.

Whether you can afford the time and effort to start over or to clean up the code depends on the project and the resources available. For critical multiuser systems, you must budget not only your own development time, but also user time for testing.

For a system that has been running for years and years, users might have gotten out of the habit of testing code. In fact, they might actually have never tested solutions that have always worked and have just grown and grown without the benefit of testing.

One thing that can help the conversion project is to plan right from the start to do the project at least twice. The first conversion will give you an idea of major issues that need to be resolved. In other words, if you can’t do a basic task, you have to resolve that issue.

A second conversion may incorporate changes and enhancements subject to the resources available. Testing can continue with this version. Having successfully tested the second conversion, you can then do a real-life conversion, applying any changes you made during testing. At that point you are ready to go live.

Preconversion Tasks

You can and should do a number of things before converting older solutions to a new version of FileMaker. Your preconversion tasks vary somewhat from solution to solution, but some categories of tasks are still common to most solutions.

Our comments here are aimed at people who are converting older relational (multifile) systems of some complexity. The purpose of doing any preconversion work at all is to make the post-conversion work go more smoothly; for single-file and simple relational solutions, you might not need to have rigorous conversion plans like this in place.

Document Your Solution

The more familiar you are with a solution, the better your conversion will go. Even if you’re the sole creator of a system, having up-to-date documentation comes in handy during the conversion process. We recommend having at least the following items:

• An ER diagram—If you’ve never taken the time to formally create an ER diagram of your system, now’s the time. For a refresher on creating ER diagrams, see Chapter 5, “Relational Database Design.” If you are converting from a pre–FileMaker 7 database, your ER diagram can be done roughly on a piece of paper. When you are in the modern FileMaker world, you can use the Relationships Graph with its documentation and design tools to produce a more complete ER diagram.

• Printouts of field definitions, scripts, and layouts—You might balk at the thought of actually printing out and organizing all these documents, and some people might indeed find that creating PDFs rather than printing works well for them. Many subtle changes take place during conversion, and it’s very helpful when looking at a script or calculation formula to be able to compare it with the original. One nice thing about hard copies, of course, is that you can annotate them as you go. You might, for instance, check off buttons on screenshots of layouts as you test them, noting whether everything worked as planned or needs post-conversion attention. The printouts become both your testing plan and your post-conversion audit trail.

• An access privilege matrix—This is simply an overview of the privilege settings in your current files. Create it in a database, spreadsheet, or text document; the location really doesn’t matter.

If you use FileMaker Pro Advanced, you might want to create a Database Design Report (DDR) of your old solution as part of your documentation process. When you are finished, save the converted solution and its own DDR for reference.

Do Some Housekeeping

In addition to file references, you can avoid other potential post-conversion problems if you do a bit of preconversion work. You can actually identify much preconversion work by examining the alpha conversion files. You might, for instance, discover that you have objects with illegal names, which are placed in between curly brackets during conversion. These can be changed in the original system so that by the time you’re ready to do your beta conversion, they’re no longer an issue. By doing as much work as possible in the pre-beta conversion stage, you reduce the amount of time and work required to get your converted files ready for production.

If there are scripts, layouts, relationships, external data sources, passwords, value lists, or fields that you know are no longer used or needed, try to eliminate them before conversion. If there has been case inconsistency in the entry of passwords in your current system, take the time to standardize them. These efforts will be rewarded by shorter conversion time and having less to test after conversion. Any other housekeeping in the original files can only be beneficial, including organizing scripts, editing object names, and archiving old data.

Converting Files

The actual conversion of files from previous versions of FileMaker is a simple task. In many cases, it consists simply of opening a file in a FileMaker Pro 12 (or later) version of FileMaker, and responding to the dialog shown in Figure 20.1. Everything just works.

Figure 20.1. Many files can be converted with a single mouse click.

This one-click conversion works with a single-file solution subject to some of the issues described later in this chapter in “Potential Conversion Issues.” If you have a multifile solution, you need to convert all of the files to .fmp12.

Figure 20.2 shows the relationships diagram for a two-file solution. Note that the People table title is shown in italics, which indicates that the table is located in an external data source rather than in the same file.

Figure 20.2. Tables in external files have italicized titles.

At this point, if you try to use the external table, FileMaker Pro will be searching for the file with an .fmp12 prefix. Until you convert it, FileMaker Pro will be unable to find the file. This means that you should start by converting all of the files in your solution, possibly by dragging them all onto FileMaker Pro 12 and converting them in a single operation.

Post-Conversion Tasks

As discussed in the previous sections, you can avoid many potential post-conversion problems by doing some preconversion work on your old system. However, a number of tasks can be done only post-conversion.note

You should begin a list of post-conversion tasks during your exploration of the initial conversion files. You’ll spot problems and potential areas of improvement. Anything that can’t easily be fixed through preconversion work should go on your post-conversion task list. Keep in mind that you’ll end up destroying the alpha files, so don’t spend too much time or effort fixing problems. Some fixes are necessary just so that you can continue your exploration; you might opt to do other fixes just so that you can test the results.