Troubleshooting

 <  Day Day Up  >  

graphics/troubleshooting_icon.jpg

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 Pro 7, 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 Pro 7. 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 most difficult post-conversion tasks you can attempt is to consolidate tables from multiple files into a single file. Typically, you would begin by creating a second table in one of your files, with fields named the same as those in one of your other files. 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 right. This also affects portals and scripts that reference fields through the changed table occurrences.

If you ever need to repoint a table occurrence from one base table to another, be aware that you may have these problems. In some solutions, it may be simple to respecify all the affected objects manually. In more complex solutions, you need to make sure that the field IDs in the two tables match correctly. The best way to do this is to use a tool called FMrobot, from New Millennium Communications (www.nmci.com). FMrobot automates the process of creating tables and fields. Other third-party tools may also become available to help with the issue of consolidation.

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 Pro 7, you may be better off rewriting your system.

 <  Day Day Up  >  


QUE CORPORATION - Using Filemaker pro X
QUE CORPORATION - Using Filemaker pro X
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 494

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net