As is often the case, you can use scripts for this.
- Save a clone of your development copy (save a copy as...) to get a copy that is clear of any old data or data you entered for test purposes.
- Use a script that imports data from each table in the old copy in turn.
- Include script steps that use Set Next Serial Value to update serial numbers fields so that your new file won't create records with non unique serial values.
- Now swap the new file for the old.
Another option developers use to minimize the need for this is to split the database into two parts. Part one (front end) shows all layouts etc. and is the file users open to use the database. It has no data tables of its own. Instead, it uses external data source refrences to link to the data tables which are defined in a second file (back end).
With this design structure, you can often deploy a new update simply by replacing the currently used front end file with an updated copy and no importing required since many updates do not require modifying the table definitions.
Hmm, both of those solutions sound pretty difficult. Surely there must be an easier way, given Filemaker praises itself as the world's easiest database or somesuch...
The script based approach sounds pretty difficult to put in place, while the second is impractiable while I am constantly adding new parts to the database through the addition of new tables, new fields to old tables, and new options for some fields.
Unfortunately there is no easy way. I just went through setting up a development version myself. Maybe these posts will help you.
Actually, the process for automated imports isn't all that complex. Once you can script the importing of data from one table to another, you just repeat the process for each of the other tables.
Splitting a file into front and back ends isn't terribly hard either. You can save a copy of your file and then redirect all the table occurrences in one file to the matching data-source tables in the other. That's more tedious than difficult. You can leave the layouts, scripts etc. on the back end in place--gradually becomeing out of date or you can delete them to make the file smaller. In the front end copy, you'd delete the data-source tables once you've redirected all the TO's to the second file's tables.
I'm sure you're right that "once I can script..." except I can't and it is not very intuitive from what I've seen. I have no idea how to learn it either, or where to go, and I don't even know what language it is in. While I can do simple HTML and very basic PHP (eg using "echo") that's about it. AppleScript is a mystery, but at least I know what it is called (not that that helps any).
So, while it may be easy once learned, and especially for someone who thinks that way, for mere mortals it is quite daunting.
There are books and tutorials on the subject you can look into.
Many of the script steps in filemaker match options you can select from the menus. Once you know how to do something from a menu option, you can often select the same step in a script and you'll find you are working with the same dialog boxes you were with the "manual" approach.
And of course you can take a swing at a few simple scripts to get the hang of it and ask questions here if something doesn't work the way you expected it to.
Can you suggest some simple process I could start with? And which menu item or button do I press to access "scripting"?
Find something that you are doing over and over again with one of your databases and try replicating it with script steps.
An example might be setting up a script that selects a layout, finds a particular group of records and sorts them in a specific order. (That can be done with a script as short as just three steps.)
In the scripts menu, there's an option called Manage Scripts... that brings up a dialog box where you can create, edit, import and delete scripts.
PhilModJunk is right, start simple with something you find yourself doing.
I have mentioned this a couple times in these forums, but the way I learned how to script was to use some of the "Starter Solutions" provided with your copy of FM. They have scripts built in and you can use them as examples of how to build your scripts. The scripts in the starter solutions are named according to their function, so it's easy to find one that matches your task. If you have an advanced copy of FM you can even use the script debugger to go through the scripts step by step.
Watching the script debugger is an excellent way to learn what happens when your script executes. These days where a script step like go to layout can trigger yet another script via a script trigger, make using the debugger even more valuable. The debugger alone makes filemaker advanced worth the extra $$$.