Can you explain why saving separate copies of your file is necessary? This is rarely a good way to manage your data though there are specific "special case" reasons why you might need to do so.
If your database is not hosted over a network, a script can use Save A Copy As to save a copy of the database file to a specified file name and location by using a $Path variable to specify the file name and location.
You may find this thread on $Path variables and the script steps that can use them helpful: Exploring the use of a $Path Variable in Scripts
It's kind of hard to explain and that may be my noob-ness showing. I'm not sure yet if the solution will be hosted on a LAN or FM Server. I'm creating this as a test to present to our leadership. Our group provides logistics for disaster events. Currently all files, computer or paper, are saved as an individual event. None of the solutions in the suite are related to each other, for example lodging, vehicles and resources. The only common ground would be the event name and for this solution we don't track employes/volunteers in a traditional sense.
My line of thinking (which maybe wacky) is that for now, since I'm a beginner and our end users are often challenged this method maybe the easiest way to test the solution.
Yet it can actually be simpler just to keep all the data in one file. You can set up a table of events where you have one record for each disaster event that is then linked to all the other tables that you set up in your database. When working with the database, you can then specify the desired event and see only the data relevant to that event.
One key advantage to that approach is that if you later need to produce a report summarizing data over several different events, you have all the data in one file where this becomes a very straight forward thing to do.
So if I were to go that route, now or in the future, I would need to do the following (at a minimum):
Create a table for events
Create an event ID and add it to the tables for the relationship
Create a script to reset all data & serial #s when a new event ID is entered
Sound about right or am I missing something?
Step #3 is not needed and potentially dangerous to your data integrity. There are a few special cases where you might want a series of numbers to "reset" to a minimum value but not as a general rule and such fields should not be used as match fields in most of the relationships that you might set up in a FileMaker Database.