Post-Conversion Tasks
Troubleshooting
Disabling Startup Scripts
I've converted a solution, but it won't open properly.
Because of the changes that take place during conversion, there are many reasons your files may not open properly after conversion. The typical cause for this is a startup script that attempts to validate for conditions that no longer are true. For instance, a startup script may check that a certain plug-in is available. If you haven't installed the plug-in in FileMaker 8, or if the interface to it has changed, your script might not be able to get by the validation check.
Another typical problem in startup scripts is checking to see that some set of related files is open. The DatabaseNames function used to return file extensions of open files, but doesn't do this in FileMaker 7 or 8. Validating that foo.fp5 is open, for instance, may cause a startup script to deny entry into the system.
If you experience problems opening a converted solution, try disabling the startup scripts in the pre-converted files and try again.
Repointing Table Occurrence References
After conversion, I've attempted to consolidate tables from multiple files into a single file, but the relationships, scripts, and portals all get pointed to the wrong fields when I repoint the table occurrence references.
One of the more difficult post-conversion tasks you can attempt is to consolidate tables from multiple files into a single file. In FileMaker 7, you would typically have begun by manually creating a new table in one of your files. The new table would be defined with fields named the same as those in one of your other files, the intention being to consolidate the second file into the first. Among other tasks, you would have to "repoint" relationships to table occurrences based on the new, consolidated table. On the Relationships Graph, when you repoint table occurrences from the external table to the new internal table, the match fields involved in the relationship may change, even if you've taken great care to keep all the field names exactly the same.
This happens because the match fields don't resolve by name, but rather by field ID. Therefore, if you create the fields in a different order, or have ever deleted fields, thereby leaving "holes" in your field IDs, the relationships won't match up correctly. This also affects portals and scripts that reference fields through the changed table occurrences.
|
FileMaker 8 makes this type of consolidation a great deal easier. You can move tables between files in two ways: either by using the Import feature in the Define Database dialog, Tables tab; or by copying and pasting tables between files (you'll need FileMaker Pro 8 Advanced for this). Both of these methods will preserve the field IDs from the original file, and all relationships and references will continue to work as expected. |
The moral of the story, of course, is that you should be using FileMaker 8, and we especially recommend you use FileMaker Pro 8 Advanced for conversion work.
After consolidating tables into a single file, be aware that you still need to move all your layouts, scripts, value lists, privilege settings, and data into the new file. None of these is a trivial activity. If consolidation of tables into a single file is one of the goals you hope to achieve from migrating to FileMaker 8, you may be better off rewriting your system.