You can and should do a number of things before converting older solutions to FileMaker 8. Your pre-conversion 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 pre-conversion 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.
Also, by conversion here, we mean beta conversion rather than alpha conversion. In fact, many of the pre-conversion tasks that we discuss will cause you to want to make new alpha sets of the files. The simple difference between alpha and beta conversion files (as you'll recall from earlier in the chapter) is that alpha files are meant to be experimented with and thrown away, whereas beta files are intended to be turned into your new solution.
Prepare for Conversion
Converting a solution entails much more than the physical creation of new, upgraded files; you need to prepare both yourself and your environment for the conversion. The process goes faster and smoother if you spend a bit of time up front planning out the details. The specific preparation tasks you should do include the following:
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:
If you use FileMaker Pro Advanced, you may want to create a Database Design Report of your old solution as part of your documentation process. Third-party tools such as MetaData Magic (from New Millennium Communications), Brushfire (from Chaparral Software), and Analyzer (from Waves in Motion) also are excellent documentation tools and are all highly recommended.
For more information on third-party documentation tools, see "Documenting Your FileMaker Solutions," p. 841.
Fix File References
Whenever you link one FileMaker file with another, FileMaker uses a file reference stored in File A to locate File B. The operations that may require file references include defining relationships, performing external scripts, creating value lists based on the contents of fields in another file, performing an Open script step, and scripting an import from another file.
File references are visible and editable in FileMaker 7 and 8 for the first time. In previous versions, they existed, but were hidden "under the hood." When you convert files created in earlier versions, all the old file references are suddenly visible. You may be in for a bit of shock, in fact, when you examine file references in a converted solution and discover a hornet's nest you never knew existed.
To understand how that hornet's nest was created and why it can be difficult to untangle, you must understand how FileMaker managed file references in previous versions of the product. Prior to FileMaker Pro 5.5, all file references were stored as absolute paths: When you define a link from File A to File B, FileMaker remembers the full path to File B. On Mac OS X, that might look like /Macintosh HD/Documents/myDatabases/File B. On Windows, the full path could be something like C:/myDatabases/File B. If the link were to a hosted file, the link might include the IP address of the hosted file, as in 192.168.100.87/File B. If the hosted file were on the same subnet as the person defining the link, then the IP address wouldn't be stored; an asterisk would appear in the file reference instead.
The main problem with absolute references is that they tend to cause problems when you move files from one machine to another or rename files or folders. In those cases, FileMaker would pop up a message to the user saying, in effect, "I can't find File B...where is it?" You would re-establish the reference by pointing to the moved or renamed file. But rather than replace the previous reference, FileMaker would store the new path as an additional search path for the given link. If you had a file that had been developed over the course of many years and/or on many different machines, you may have had dozens of absolute paths stored in your files. If you ever had problems in previous versions where FileMaker would seemingly irrationally open the wrong copy of a given file, it was likely because there was an obsolete file reference higher up in the search order.
Another problem with file references in previous versions of FileMaker is that different linking operations might produce entirely new references. For instance, say you had created a relationship from File A to File B while the files were both open on your local computer. A file reference containing the path to File B would be stored. Then you moved the files to a server where they were hosted with FileMaker Server, and from your desktop you created a script in File A that called a subscript in File B. An entirely new file reference was created for the external script call.
FileMaker Pro 5.5 introduced the option to store only a relative path when creating links between files. This went a long way to solve the problems caused by renaming or moving files. Rather than locate File B with a full path reference, a relative reference simply indicates the path to get to File B from File A. For example, the relative path may be ../File B, which would indicate that FileMaker should look for File B in File A's parent directory.
Conversion of File References
So what happens to all of these obsolete and redundant file references during conversion? The conversion routine does try to do some consolidating and eliminating of file references that are no longer needed, but in most cases, you'll still end up with a bit of a mess. As an example, Figure 18.4 shows the file references from a converted solution. The names of converted file references are simply set to the filename plus a counter if there are multiple references to a given file. Notice that there are no less than five separate references to the Mainmenu file. The fact that there isn't a "Mainmenu 3" or "Mainmenu 4" makes it clear that in fact the conversion routine did identify those as unneeded. The conversion log also explicitly identifies any file references that are removed during conversion.
Figure 18.4. In a solution that's been around for a few years, it's likely that you have a lot of redundant and obsolete file references.
There are several potential problems that you may experience using a converted solution with file reference problems. The first is speed: FileMaker looks for files in the locations specified by the file references, in the order in which they appear. A complex solution with obsolete file references may take many times longer to open than one with clean file references. (The extra time is taken up as FileMaker scans fruitlessly through the obsolete references trying to find the file.)
After conversion, you can, of course, manually change all the obsolete paths to updated, relative paths. In a complex solution, this may require manually editing hundreds of references. After you're finished, you'll have solved the problem of obsolete references, but not that of redundant references.
The problem with redundant references is maintenance. If you have five file references that all point to the same file, every time you set up a link to a file, you have to choose which of those five references to use. If you ever need to update the reference, you need to update it in five places. That may be an acceptable short-term solution, but eventually, you'll want to eliminate the redundant file references.
Simply deleting redundant file references can have potentially disastrous consequences. Every link that uses that reference, be it an external table occurrence, a value list, or an external script call, will be broken and will need to be repaired manually. The proper way to remove redundant file references is as follows:
Pick one of the set that is to survive the consolidation.
Rename all the other file references in the set so that they include an easily identifiable text phrase. DELETE ME works well.
Run a DDR report using FileMaker Pro 8 Advanced.
Open the DDR report in a text editor or word processor and search for your text phrase to find all the objects that use a redundant file reference.
In your converted files, manually change the file reference used by these objects to the canonical reference for that set.
Run a new DDR report to make sure you haven't missed any references.
Delete the file references that are no longer needed.
Be sure to make a backup of your system before you start playing with file references; a small mistake such as deleting the wrong one can have far-reaching consequences.
MetadataMagic to the Rescue
Cleaning up file references in a converted solution can be a very time-consuming and frustrating process. Thankfully, there's a tool called MetadataMagic, distributed by New Millennium Communications (www.nmci.com), which enables you to clean up file references in your system prior to conversion. The File Reference Fixer, one of the tools of MetadataMagic, provides several options for modifying file references. If you use the Auto-Fix function, only the most recently created relative path to a file is retained, and all internal links are updated to use that reference. Obsolete file references are then removed from the files.
In a complex solution, you may be better off using the Consolidate and/or Set Relative-Only functions. For instance, if you have files that span multiple FileMaker Servers or are located in multiple folders, the Consolidate function simply changes multiple and/or redundant references to a single file references.
If you clean up file references in your old solution, the conversion process takes less time and you're left without a severe post-conversion headache. Figure 18.5 shows the post-conversion file references of the same file depicted in Figure 18.4, but this time the file references were cleaned up before conversion with MetadataMagic.
Figure 18.5. If you run File Reference Fixer before conversion, the file references in your new files are much easier to troubleshoot and maintain.
It's easy to see the improvement here. All the file references are now simple relative paths, equally well suited for deployment as a single-user solution or by FileMaker Server. Before using File Reference Fixer, be sure to read the documentation and practice on a set of test files.
Do Some Housekeeping
In addition to file references, other potential post-conversion problems can be avoided if you do a bit of pre-conversion work. You can actually identify much pre-conversion work by examining the alpha conversion files. You may, for instance, discover 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'll reduce the amount of time and work required to get your converted files ready for production.
If there are scripts, layouts, relationships, passwords, value lists, or fields that you know are no longer used or needed, try to eliminate these 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.
Post Conversion Tasks
Part I: Getting Started with FileMaker 8
Using FileMaker Pro
Defining and Working with Fields
Working with Layouts
Part II: Developing Solutions with FileMaker
Relational Database Design
Working with Multiple Tables
Working with Relationships
Getting Started with Calculations
Getting Started with Scripting
Getting Started with Reporting
Part III: Developer Techniques
Developing for Multiuser Deployment
Advanced Interface Techniques
Advanced Calculation Techniques
Advanced Scripting Techniques
Advanced Portal Techniques
Debugging and Troubleshooting
Converting Systems from Previous Versions of FileMaker Pro
Part IV: Data Integration and Publishing
Importing Data into FileMaker Pro
Exporting Data from FileMaker
Instant Web Publishing
FileMaker and Web Services
Custom Web Publishing
Part V: Deploying a FileMaker Solution
Deploying and Extending FileMaker
FileMaker Server and Server Advanced
Documenting Your FileMaker Solutions