Runtime backup

[Greg G]

I have been working on a way to have a backup and restore function for my FMP solution. What I came up with is this...

I created a simple DB in a seperate file from the main solution that imports the FMP files that make up my solution into container fields and then exports the contents to a backup folder. It does the reverse to restore the files by importing them from the backup folder and copying over the main files by exporting to the root runtime folder. In general this works great if your running it in FMP. When you bind the whole thing into a runtime it fails. Running the backup sometimes crashes the runtime and running the restore always crashes the runtime. I guess that once the runtime is open it is always accessing the individual FMP DB files that make it up so when my backup/restore function tries to overwirght the files on the restore it doesn't like it.

My work around for this was to bind the backup/restore utility as a seperate runtime.

1st question: Did I do this in a good way or should I be trying a different method of creating a backup/restore function?

2nd question: With two runtimes I seem to loose any connectivity between them. I can't figure out how script a button in the main runtime to start the backup/restore runtime and then close itself. As well as do the reverse from the backup/restore.

Thanks,

Greg

[Vaughan]

Use the Save a Copy As... command to create copies of all the files. Save them into a Backup folder on the hard disk.

[Greg G]

Thanks for the tip Vaughan. I will revisit that idea for the backup side of the function. I avoided it at first as it requires running a script in each file whereas I could close all the main files and use one script in a seperate file that would be needed anyway in order to create a restore function.

But the hard question of how to automate the copy of these file back to the root runtime folder to "restore" the backups remains.

Any takers?

Greg

[Inky Phil]

Hi Greg

It is much the same but in reverse. A script in each file which deletes all records then imports a complete set from the backup files that you have created. Once you have all the records in you need to reset any autoenter serials to start entering from the next highest number and that's about it - you have to do this for all tables within the file of course.

One script can still run this from within the main file but calling external scripts once it has sorted itself out.

The only problem that I found was that I had this running nice and neat in 7 but when i went to 8.5 I could not for the life of me get the runtime version to import from a sub-folder. The none runtime would do this fine but the runtime would just refuse to see the files in the subfolder.

I got round this in a very kludgy workaround whereby I hardcoded to save each file under a different name (ie BU_main.fp7 rather than main.fp7) and saved the copy into the same root folder as my original files. My import routine then imported from the BU_ files.

This was very unsatisfactory but in the abscence of anything else it worked!!

Like I said this behaviour only had to be accounted for in the runtime - not the original

HTH

Phil

[Greg G]

Hey Phil, good to hear from you again. I remember this procedure from another post you made somewhere. Frankly, I avoided doing this because of the volume of tables I have and all with auto-enter serials. It seemed to be easer to use a few container fields and just import/export the contents as necessary. Like I said it does work great until you make it a runtime. I solved half the problem by binding the backup/restore file as it's own runtime. The only thing I can't figure out is if there is a way to start another runtime with a script. That would make it sooooo much easer. PLEEEEASE say it's possible!!!

My spirits are slowly going down hill with this one.

Thanks again. I always appreciate you advice.

Greg

[Greg G]

Ok, if there is a way to script the opening of a runtime from another runtime I'm stumped.

Anyone have any ideas?

Greg

[aholtzapfel]

can you use an applescript or send event on windows? I don't remember if those are avalible in runtimes. I think they are.

[Greg G]

Send event is cross platform not Applescript. But I tried using a send event (mac) and everytime I pick the other runtime app it tries to open it under the current runtime. Can't figure this out.

[Greg G]

OK, I finally got this to work...no thanks to my own stupidity. The only problem here was me! Here is what I did incase anyone wants to duplicate this type of backup/restore function.

Basically what I want to do does work. My problem was that I had a couple of random calcs in the backup/restore file that referenced the db files I was trying to backup and restore. Therefore, those files were not closing and allowing me to copy over them. That is why it would crash every time I tried to restore a backup. Oddly enough this didn't cause any crashes when running the native files in FMP only in the runtime. Once I removed these calcs it worked just fine.

Personally I think that this is a more efficient way to run a backup/restore than using scripts to delete each tables data, then import all of it from the backup files. It's faster to create and run when there are many tables and lots of records.

For anyone who cares this is what I did:

-Create a new DB file that acts as the backup/restore interface.

-Use scripts in this new file to close all other DB files you want to backup/restore.

-To backup, either script the SaveAs function or script the import of your DB files into container fields and then export them back out to the location of your choice.

-To restore them you just import them from your backup location to container fields and export them back into the application folder and let them overwrite the existing files.

I also use this process to create a load/archive function for a DB that can only be used for one project at a time. The user can archive the currect project file anywhere and load another to work on. It's just like saving and closing a file and opening another. You will also not have to update anything as you add or change your tables in your main DB files which is nice too.

Hope all this info helps someone.

Edited July 12, 2007 by Guest