My served, multi-file inhouse invoice solution has been converted from FMP 6 to FMP8.5. All navigation works fine. Bad file references that were crashing FMP 8.5 have been repaired.

Now the problem is many scripts with relationships are not working and I glean it's due to the new Commit Record step and Refresh Window Flush Cached Join Results step. Also possible, the converted scripts now show $ where there may be a conflicting symbol and now may have erroneous parenthesis, although I see no conflict but need to research this some more.

Question(s)-

There are many Set Field steps. Should there be a Commit Record step after all or most of these, now?

Can one have too many Commit Record steps to cause harm?

Are there any more "Conversion Gotchas" particular to relationships and scripts to look out for?

Thanks in advance!

Stephen Ray

Good questions.

There are many Set Field steps. Should there be a Commit Record step after all or most of these, now?

If you set a bunch of fields on a single record, you'd only use Commit at the end, not after every Set Field. It depends what you're doing, though; e.g., if you're setting a global field to drive a relationship, you'll need to commit it.

Can one have too many Commit Record steps to cause harm?

Not really. You are in a sense making more "work" for the file, so there is a performance hit, but again depending what you're doing it might be imperceptible.

Are there any more "Conversion Gotchas" particular to relationships and scripts to look out for?

One of my anti-favorites is the different behavior of Go to Related in the case where no related records exist. In earlier versions of FileMaker, you'd end up in the related table with a found count of zero. Now, you simply stay right where you are. This can set you up for extremely dangerous situations (e.g, deleting records from the wrong table). My recommendation is to always test whether related records exist -- not IsEmpty(the::related) -- before doing GTRR.