Help!! Updating a runtime DB with Scripts

[macintaz]

Is there any way to update a Runtime Database that I am sending to users that don't have a clue?

I need it to replace the old runtime DB and import its data

Is there a way to script this or should I do it another way?

Thanks

Macintaz

FileMaker Version: Dev 6

Platform: Mac OS X Panther

[rogermax]

If you have not published the runtime yet, then script it all in advance. I have a set of scripts that go through each file and invoke the Show All command, then it saves a compressed copy with a different name and extension. In the upgrade files the scripts include importing from the copies that have been renamed, making sure that the import either uses matching names or has a particular setup and saved in the script. It has worked very well for me.

Then with the same binding key you could replace the old runtime files with the new or just give them the whole new solution.

[Fenton]

There are ways to script it. But they are still going to put the folder with the new file(s) in the right place. Hopefully they can do that. These are the basic steps, all of which must be controlled by the new files, running in a folder right beside the old ones (unless it's only 1 file, in which case the same folder).

1. Show all records in Old, switch to blank layout

(scripts in Old, called by New)

2. Import into New (scripted order) on blank layout

3. Set New's serial ID field to next serial in Old (see attached file)

4. Close Old, close self

5. Remove " Clone" or " New" or whatever from names.

[manually, scripted method is available, but somewhat dangerous.]

Serial Update.zip

[Fenton]

If you cannot reliably call a Show All Records in the older file, and cannot trust the client to do so, then it's safer having them send you the files and doing it yourself.

[Fenton]

One last comment. The Initialize script in my files is not very safe. It just deletes all the records in the example, so you can test it over and over. However, in real files, if you have any relationships with "allow deletion of related records" and you delete all, you're going to delete all those related records -- in the other files (which are the regular files, not the NEW files!, because that's where the relationships go).

If you Replace the ID with "", then you can safely delete without taking out the related records. My "Save As" script does this. That script is turned off for now, 'cause it's dangerous. It overwrites the original file with the NEW file. If you don't completely understand it, you'd best not use it.

Also in real life, you'd run this from another file, which would just call the Update script(s). You don't want the Update script showing in the Script Menu of the real file. It's also nice to put a little message, "Updating file SerialNum.fp5, please wait" in the separate file, since these things can take a while.

[macintaz]

Thanks guys I've got most of this figured out.

I guess my big problem is windows XP on the mac I can create a Apple Script to delete the old version of the Runtime and replace the new. I guess this is my problem replacing the old with the new

Right now my script

1.exports the data to a seperate folder

2.opens the new

3.closes the old

4.imports the data to the new

But I still have the OLD Version of the Runtime I need deleted/Replaced

Peter

[Fenton]

I have a routine in my attachment that overwrites the original with the new file. It's turned off (by an If test). You can turn it on; it's pretty obvious how. It's very important that the files be correctly positioned, and that the original is closed then (or god knows what could happen). I have a step to close the original; but it really should check again with the PatternCount(Databases()) functions to make sure.

To be really slick, you can clone the New file first, so they end up with a clean backup clone, which they can reuse. They'd still need to delete a file at the end. It would be worth them buying the Troi File plug-in or equivalent ($55) to handle that last deletion. That would give you the control you have with AppleScript.

[rogermax]

Fenton has given really great advice here.

1.exports the data to a seperate folder

This is why I simply save the "compressed copy as" and change the name and extension. Saves the export time if you have loads of records and essentially hides them from opening on their own while still containing the data as a backup.

Compressed of course does not mean zipped, just the FMP compression. You can name the import files in the script even with the new extension and it really works nice. I have clients all over the US so I can't be there to do it for them.

Even though my tag says Dev7 I am using this on v6 as I have not converted the solutions yet.

FileMaker Version: Dev 7

Platform: Windows XP

[andygaunt]

Another option available is a great tool called Update Genie.

http://www.hi-voltage.com.au/updategenie.php

Requires paying some money but it can really help in the updating of solutions.