You'll need to take a clone of your update and import all the data from the tables in the older version into your newer version. It's a bit of a job if you have lots of tables, but it can be scripted so that you tell them, "close and put the old file in this folder, the new one in this folder and click the update button".
You'll also have to script resets on any auto-entered serial numbers so that they are correctly set up to assign a value that doesn't duplicate serial values already assigned.
The big pain is that you'll also have to update any accounts and passwords in the new file to match those given in the old. (Or just set them with dummy passwords that require a new password on first access.)
Its no wonder this isn't highlighted in Filemaker manuals! What a pain. In Delphi and other development tools, becasue the data and User interface are separate, the application can be updated any time with full confidance that all data has not been amended, corrupted or changed. simples!
This to me is a MAJOR drawback for Filemaker. Its the user paying for developer time when it shouldn't be necessary.
Sorry, PhilModJunk, not getting at you personally.
Hey, I'm just a fellow user so complaints aimed at Filemaker miss me entirely:smileywink:
It is possible to split your database into two files, a back end for data and a front end for the interface. It doesn't always eliminate the need for importing data into a new version of the file as you may have to alter schema from time to time, but it will allow you to avoid imports for layout tweaks. It can make filemaker based security settings a bit more complicated as the two files will need to have matching account names and passwords so the front end can open the back end smoothly, but it might be worth a look for you.
Splitting a Filemaker File:
- Always keep back up copies so you can revert back if you mess things up.
- Start with two exact copies of your database file.
- Rename the files so you can tell the front end file from the back end and so that they can occupy the same folder if desired.
- Open the file intended to serve as your Front End.
- Go To Manage | Database | Relationships and double click each table occurrence box.
- Use the add filemaker datasource option in the data source drop down to find your other copy and connect each Table occurrence to the matching table in the other file.
- Delete all your tables from the front end file.
- If you want, you can now open the back end copy and delete all layouts, scripts etc.
- Test to make sure you didn't break something and use FMP advanced's database design report to check for the key words "missing" and "unkown" to confirm that you haven't broken a reference somewheres.
Thanks for the heads-up on how it can be done. Will ahve a look at that in due course, as I need to re-write an old Delphi application for a Children's nursery and they are based in UK, miles away from me.
Phil, thanks for the explanation. I have been pondering data-separation as my next lesson toward building my own commercial applications. After all is done and in place let's say for APP.ver1 when the time comes to roll-out APP.ver2 I just overwrite the front-end file with the new one? And all the relationships will continue? [barring my having made an error]
That's the theory anyway. The key here is that this type of "update by swapping front end files" will work as long as the only changes are made to the front end portion and no data is permanently stored in that file.