Hi

I

So what's in the "Backup" script? It's the one doing the deed, we need to see it the most.

I don't see the need for the Pause Script steps -- they're just wasting time. The Exit Application step is redundant since the file is closing anyway.

Are the files single- or or multi-user? Multi-user files can only be backed-up if there are no guests using the file and the Save a Copy As command is issued from the host machine.

Do the files live on the local hard disk or on a shared network volume? The files *should not* be on a network volume, they should live on the local hard disk.

Hi Vaughan

The back-up script is going to around 40 db

Hmmm... what format is the XML file? Text, or something else? How would opening the XML file generate the original error message?

The method that I've used to create backup files is to use the "Save a Copy As..." command in the shutdown script, specifying the file name and path (same name as original file, but saved into a "backup" folder).

That way if the original file gets corrupted it can easily be replaced. (As opposed to having to import data into a corrupt file, which will leave the user screwed).

My rezones for exporting to

The data is exported as xml, but that's all that's exported, the data. The interface (scripts, layouts etc) won't be backed up. The Save As command saves the whole file.

I'm just getting a grip on XML, so be patient with me... My understanding is this: XML is a technology not a solution. If you export to XML you still need to define the format of the data. FMP has a couple of "default" XML formats, are you using one of these? Or have you created your own style sheet thingy? Importing XML data into FMP might vreate a new file, but it won't recreate the old file and interface.

Have you actually tried to do a full restore from the backed-up data?

Backing up to the local hard disk isn't going to much use with a disk crash. Do the users also backup to external media?

I think you have miss understood the main problem, this could be due to my poor English.

The back-up to XML is just to save the data and I don

Ok I understand.

Backup the files, then change the scripts -- in one solution I made, each file has a "backup" script but it's not a shutdown script. Instead, the "main" file of the solution has a backup script which looks like this:

Perform Script [External, file1::backup]

Perform Script [External, file2::backup]

Perform Script [External, file3::backup]

Perform Script [External, file4::backup]

...

Exit Application

Similar to yours just run differently, and a bit easier to debug since you can control each file's backup indivisually. Give it a try and see what happens.

I think I found the problem late last night. My script was actually exact the same as you mention.

The problem has been that I was of rezone I don

So I

I think you'd better remnd me how the files are being hosted -- are they on a dedicated server running FM Server or FileMaker Pro, or are the files on a shared network volume that users have direct access too? What versions and patch levels?

The close script also performs a backup doesn't it -- to XML if I remember. How about you do a test and put some error checking into one of the files that are getting sorrupted to display a message if the export creates an error. That way you know what's happening.

Time to start testing.

I

I have 12 files I backup daily (approx. 45 to 70 MB by the end of the year). I have been playing with xml as a backup, what I have found is 1 file takes forever to export. So I am back to my Save a copy as Script.

In each file I [save a copy as File Bkup] to a folder in my main data folder then I run my close down script. After I am done with backup I use Stuffit or a Zip program to save disk space. In the close down script I make sure the child file shuts down first an lastly the parent file, then I exit application. I run this on Mac OS X and Windows 95 through 2000 and NT Server with no problems. I also read your previous posts about updates. I feel the Save a copy as Script is a good way, to always have a current copy of a file, in case you get a corrupted file in between updates then you always have a good file backed up, not just data.

Good luck with your solution.

Dean