Mostly, modify development copy and then import the data.
You can split your database into two files.
File 1, the front end, has all layouts and scripts. File 2, the back end, has only the tables and any relationships needed to support calculation fields and auto-enter requirements. Since most updates will only involve changes to to File 1, you can then update the file by swapping old copies of file 1 with the new and you won't have to import data.
In hindsight, that sounds like a good option, but at this point, I'm worried about breaking too much or having to start over on some aspects. Guess I might just have to try it and see how it goes. Thanks.
It's actually pretty easy to split a database into front and back ends.
Save a copy of your file, then open the file you want to use as your back end and use Manage | Database | relationships to redirect each table occurrence from the current file to your 2nd copy. Then delete the tables from the front end file and the scripts and layouts from the back end file. As always, keep back up copies so you can revert back if things go awry on you.
I'll go ahead and try it out. I had just thought that there would be some problems with linking to a new file, but I suppose if the table instances are named the same as they were previously, then nothing should break. Thanks.
Just my personal opinion on data separation in filemaker....
I almost went this route myself, however am finding most updates involve adding new fields etc, so for the effort required to convert a single file into front end / back end seems pointless
There are also some issues with how data is evaluated which you may come across, altough there are workarounds to most of the issues,
Ive now decided its more practical to work on a single file basis, then release a copy of that blank file with a scripted data import to bring data in from the clients original file.
I suppose it also depends on the amount of data to be held in the database, how frequent changes are to be made and also what types of changes you are planning to make.
If you are likely to be adding lots of new database fields, calculations (in the data table) etc, then I dont see any benefit of separating the UI from the data