If the file crashes, the closing script won't have a chance to run.
On the other hand, filemaker regularly and frequently saves data automatically.
If you can avoid using global fields for this data, you'll be much better off as filemaker can save it for you without the need for a closing script.
There are ways to set up a table using the cross product operator "X" instead of "=" that can serve many of the purposes of a global field, but, unlike globals, will save data automatically and which will persist when a client closes the file.
Thank you very much for this... Sounds like a much better idea than the way I've been doing it so far: The pieces of data that need to be stored are being gathered in a global variable separated by carriage returns, and at the end of a session records are being created in the "Report" table, one new record per value.
So, creating a cartesian join should help to store what is necessary right away.
Thanks a lot! :smileyhappy: Mike
The devil is in the details.
It depends on the structure of your database, what this information represents and how you need to use it.
Interesting . . . I use a multi-file solution in my business. Each file has a "closer" script . . . some of them are simple cleanup routines. I'm not sure I've ever had a true FM crash! If this happened, the scripts would simply do what they do the next time the files are closed. I believe it's important to NOT allow closing scripts to substantially alter existing data. Cleaning up "empty" records, resetting where you're going to be next time the file is opened . . . fine, but depending on data to be updated would be a scheme completely undone by a crash.
My 2 cents,