To move data from one version to another, you have to find all the records in the original file, then import them from table to table using view by matching names. That's fine if you only have a table or two to import, but if you have many tables, it becomes a lot of work and there's always the risk of overlooking or forgetting to import data from one or more of those tables.

For the example I discuss in this article, I'll assume you have a single file with multiple tables. I always use a serial number field to create a unique primary key so I don't have to worry about updating the serial numbers when I import data from an old version to a new one. See the sidebar "Updating Serial Numbers" for a script step to do the work for you.

The routine requires two scripts and one global field. Your solution sets the global field when you run the first script (which prepares the original file for the upgrade) and checks that the user isn't trying to import data into the same file he's currently using. In other words, you set the original file to 1 and the new file will have that field empty; when the import script checks the field value and sees that it has a 1 in it, it knows the user isn't importing into the correct file.

You'll need one layout for each table in your solution; those layouts don't have to have any fields or data. You only need them so you can go to the table occurrence.