[color:red]HOT TOPIC FOR EVERYONE. When creating a runtime application that will be upgraded after initial deployment, the ability for a client to migrate their data from the old to the new is critical. Being able to backup the data in general is at least of equal importance.

My question, then, is a simple one: "How is it done?"

If the number of possible records is dynamic, and I create an Export script to backup fields a, b, c, and d, how do I tell it to do this for all the records? Is each backed up record a separate text file that has to be reimported one at a time (say it ain't so!)?

Thinking about it, if I created a "Save As" script in a runtime, the data is now saved. But what file format should it be in (.fm7?... .txt?)

Even if that were done, how do we get the data back into either the current runtime or the upgrade?

The .USR in the runtime folder is exactly the same as an .fp7 (it's just copied when creating a runtime). You can change the extension to .fp7 and then open the file like any other FileMaker file.

Now that you have a normal FM database, you're back to the age-old question: whats the best way to migrate data? I suggest reading the Separation Model forum for pros and cons.

The easiest way I've found to handle this is to create separate export files for each table. I'm not aware of how to 'combine' these into one file.

It's easy enough to create a script to export all of the needed tables and fields with one button click. The script would have one export step for each table. Then create another script/button to import all of these back in (after the update has taken place).

With this method, it's best to hard-code the filepath and name of each file. Then the client doesn't have to see any screens or deal with naming anything. I save them in the root directory, but have found some clients have their computers locked on where file read/write privileges are concerned. I remember something about FM8 being able to have files write to the desktop now, but can't remember how this is done.

Another thing to look out for - if a particular table has no records, it won't write the file. If the 'import' script looks for a file that doesn't exist, it'll give an error. It's easy enough to script for this.

Use a two file system. One file for interface, one file for data. Send them the new interface file. No import required, unless you changed calcs or relations in the data file.