There is no need to use Export Records at all for this.
A script in the new version of your solution can use a series of Import Records script steps to import the data directly from the original FileMaker File into the new. The user need only click a button to start up the process.
But be sure that your script also updates next serial value settings as well as import records and your original file should have a found set of all records on every layout in the file before you start importing.
You may also want to consider a Convert to Seperation Model as an option to use in the future.
Hi Phil, thanks - read a bit about the data separation model and it sounds like a solution that could work.
1 question came up - with the UI in 1 file and the data in another it is easy to swap the UI -- however, what happens when you add data fields to your working version or a new table? how does that get to the client's data file?
I'm sure the answer will pop out of my research ....
Gordon -- Refresh looks nice but the price is a bit heavy for schools --
If you make changes to the data file, you have to import records from the old to the new. Data Separation can reduce the cases where a data import is needed. It does not eliminate the need for imports.
This can be scripted such that the user simply clicks a button--provided old and new file copies are sitting in the same folder or otherwise in a predictable location.
Another scripted option uses insert file and a container field as a way to present the user with an Open File dialog where they select the original file and then the system takes it from there to import the data from each of the tables in the original file. This is more flexible as you don't rely on the user placing the new file in a specific location before running the import script.