Use Save A Copy with the clone option to get a copy of your file that is empty of records.
Take your friends copy and use Import Records to import all the records from all the tables in his copy of the file into the new clone.
Update any serial number fields to have next serial values greater than that found in any of the imported records.
This process can be fully automated with a script.
The need to do such importing when a new update is released can be minimized in systems that use the Convert to Seperation Model.
Hey Phil thanks again...who knows the future of my solution but sounds like I should consider "data separation" method, since this solution may go to other individuals.
So by when I update I would only update the "interface" file with changes to layout and so forth. Am I on the right track?
The idea behind data separation is that many potential updates only change layouts, scripts, value lists etc. When that is the case, you can replace the old interface file with the new and not need to import any data. But there will still be times when you have to update the data file's design to get the results you need for a new release of your solution. Then, you still have to import data and update serial number field settings.
So the method reduces the need for data imports. It does not totally eliminate it.
In reality, FileMaker solutions fit on a kind of "continuum":
Single File-----Data Separation------Multiple files------Multiple Files with data separation
The ultimate extreme here is that a 20 table solution would consist of 21 files--20 files with one data table each plus the interface file.
That result means that you would only replace files and import data strictly for those parts of the system that requir it. There are however, a number of drawbacks to using, creating and maintaining multiple file solutions. (We all applauded noisily when FileMaker released Filemaker 7 and we could finally put more than one table in a single file. There was and still are reasons why we applauded like that...)
Data Separation, thus is a kind of compromise between these two extremes.
Ok... Right now i have just one file with bunch of tables called workorder. So lets talk about this script...will it allow me to do everything I need with a push of a button?
It can, but if there is a script in the original file that does a Show All records on a layout for each table in the file, things work better.
What I've been able to set up is that you perform that "get ready for update" script in the original file, leave it open, then open the new copy and click a button. The script uses Insert File to open up a dialog for finding the original file. When you select the file, the script inserts a refernece to that file into a container field.
It then extracts the filepath and filename of the original file from the container field and then uses it with a series of import records steps. In cases where there is a serial number field to update, the system checks the next serial value for that field in the original file and then updates the next serial value setting of the same field in the new file to match...