updating runtimes?

[tstrait72]

Is it possible to update/patch a runtime solution? I don't want a user to need a completely new version and have to go thru the hassle of exporting and importing (if it were even possible) if a problem/bug was found. I'm sure I am a fairly new user compared to you guys here, so please don't be too harsh if this is a stupid question. Thanks.

[jasonwood]

Is it possible to update/patch a runtime solution?

No, but you can script the importing/exporting so it can be done automatically.

[dbhill]

Seems to me you can open the USR file in a standard FileMaker application, modify the data file then return it to operation with the program file.

~Dennis

[Chuck]

I'm actually working on this exact type of update routine right now. Believe me, I'm coming up, yet again, against the limitations of FileMaker.

I'm using Installer VISE to install the correct files (updater or normal) based on whether the user has an existing version of the system on their computer. If the updater files get installed (which are exactly like the normal files except in name) the installer will launch the main menu, which checks to see that it's name indicates it should perform an update. It calls scripts in the normal files to make sure that all records are found, calls script to make backups of the old files, and then imports the data from the old files into the new. Finally, it performs a save as operation, saving the new files over the old files.

It isn't perfect, and I'm still working out the details of how to get Installer VISE to do what I need, and at the end of it there are three sets of files in the runtime folder (new version with old data, old version backed up, new version with no data), but I think I'll eventually get the wrinkles ironed out.

Chuck

[SteveB]

I've done the same thing (almost) with Setup Factory. The installer determines whether it's a new install or an update by looking for the solution EXE. If it's an update, the existing files are copied to an 'Old' folder. Then, an Update file (a standalone Filemaker file) gets executed by the installer. When this Update file starts, it runs a script which sequentially runs import scripts in each of a number of data files that import data from files of the same name that were moved to the Old folder.

[T-Square]

I have to echo Chuck's message. I have had a solution in place for a couple of years for which I have tried to build scripts that automatically update an installed version with my updated version.

I continue to find Filemaker's functions sorely lacking, and Jason's recommendation to automate the importing in a script seriously begs the question.

The update process I have come up with is:

a) fire up the Update main file, which includes a clone set of files in an Update folder.

: The Update main file then fires up each file in the Update copy of the solution (there are 10), each of which imports all the records from its corresponding source file and then saves itself into the main folder.

c) Each Update file then empties itself to be sure that users don't accidently fire up a different set of files than they expect.

I have a lot of problems with this setup, and have yet to see it actually work reliably with my users. Particularly:

1) I find it troubling that it simply is not possible to see the folder to which a "Save File As" script step is directed (rather important, if I'm trying to reliably save a backup copy of my records to a neutral spot, which I then use to import into the update copy).

2) The Import records script step takes on the current import settings, and is only visible when you print out the script. Moreover, you cannot modify these settings except by re-importing. Finally, it seems that Filemaker tracks the Import settings by position, rather than by name, so if your data structure changes (for example, you have to create a new global field for a new script), this can be catastrophic.

3) The system requires that I have essentially the same scripts (backup, clone, update) in every file of the solution. Maintaining all these scripts across files is a colossal headache--in no small measure because of points 1 & 2.

I have to say that MS Access's ability to separate the interface from the data makes it much easier to manage system updates. At one point, someone in these forums offered a technique to simulate that structure, but it was so complicated that I abandoned trying to implement it myself.

David