Why does creating a backup copy need you do it in the manner you describe?
If you use FileMaker Server to host your database. You can schedule Server to make the backup copies for you on a daily or even hourly interval.
If you host with FileMaker Pro, you can use a script with Save A Copy As... to save a copy of the currently open file, but why then do you need to open the back up copy and close the master? And why import any records at all since the saved copy will contain a complete set of data as it existed at the time the copy was saved?
Yiup, I was over complicating things as bit paranoid about backing up! I have since created a few scripts that can back, create test file and import records form orginakl database...Although when I use the import script function in my script, despite entering the path and filename of host file, Fm still opens a dialogue asking to locate this file...Any ideas why? is it because the target file is not in the same file as host file?
Why do you need to import records as part of the backup?
Did you select the "no dialog option"?
I was following up on the active database alteration post i submiited last week - Basically, If I want to alter the database while it is being used, I have to create a back up, a copy ( that I can alter). Then I run a script that deleted all records from the new copy and reimports them all from the active database. Not sure if that is the best way to go about this but seems to work...ish
It's a commonly used method for updating files that contain data. I just don't think of that as part of a "backup" process as I see it, it's part of an "update" process when you need to deploy a new copy of a file that contains data tables. (With the Convert to Seperation Model method, you can often deploy updates without having to do data imports.)
There are several tricks you can use to smooth the process.
One is to define a container field and use Insert File with the Store a Reference option selected to insert a reference to the original copy of the file into the container field. You can then extract the file path and file name from this container field to put in a variable you then use with Import Records to import your records from the original file. The user thus sees an open file dialog, they find and select the original copy of the file to open it and then the script takes it from there.
Another trick is that when you use a variable for the file path with Import Records, also include a second file reference after the first that explicitly links to a file that exists at the time you define your script. You can then use this reference while creating the script to map fields and specify import options, but when the script runs, it refers to the variable for the filepath and only defaults to the second file reference if the variable does not contain a valid file path.