SCRIPT TO UPGRADE A VERSION OF A SYSTEM USED?

[siou]

Hello all..

and thanks again for all your help!!

I need to make a script that will enable a person to upgrade to a new version without losing any of the old information!

I find this really necessary, because I am constantly changing little things on my system, and then when I need to upgrade the version of my database, I have to manually move everything over...

How can I make this super dummy proof, so that anyone in my shop would be able to upgrade to the whole new system that I want to change next monday, for example?

I have a large system that is comprised of 6 seperate databases connected in many relationships...so it seems that an upgrade script would have to be very complicated...

any simple ideas?

Thanks for all of your support!!!

And have a great day and

Greetings from cold Berlin!!

Ami

[Kurt Knippel]

Basically, what you need to do is to setup and import/export routine to export all the data from the old system and import into the new system. Alternately you could simply import directly into the new system, but you probably will be using the same file names.

I think that there is also a company who makes a set of templates or plugins or something that aids in the whole Filemaker solution upgrade process.

[DanBrill]

I've done this with my solution. Keep in mind that this is a windows only solution. Apple Script could probably do something similar. It is also one of the most complex parts of my system.

When a user first installs, a dialog asks if they are upgrading or using for the first time. If using for the first time, then they just start with the empty database.

If they are upgrading, they are asked for the pathname to the folder that holds the previous version. A script then takes this information, and builds a small, 1-variable database from this. This data is exported as plain text and saved as a batch file. The batch file is called from FileMaker. During its execution, it copies all of the old data into a temporary directory that is in the new version's folder. So at that point I have a copy of the user's old data. The two advantages of this are that 1) all of the data from the old version is left unaltered. If the system crashed in the middle of the update, no problem, because we're only working from a copy of the old data, and 2) I have a subfolder in my main folder that contains all of the data I need, so I can import from these using relative references to the file names and I the relative references will work since no matter how the user had the old version of the DB set up (in terms of drive letter and pathname) I'll be importing from the temporary subdirectory that I've created.

Then its a matter of importing from those old files into the new from the temporary location, and then erasing the temporary directory. When you do your imports, don't forget to reset any serial numbers in the new file to the maximum serial number +1.

That's a pretty basic outline, but that should get you started.

This whole topic gets to the notion of divorcing layouts from the data, which is something that FileMaker is not too good at. (Here's one area -- perhaps the only area -- that I can say I like better about Access than FM.) To avoid having too many upgrades for my users where they'd have to go through the process outlined above, I have a single file that can create reports from the data in all of the other files in the solution. I can then change this one file and send the updated version out to the users. They can copy this single file on top of the old version and go right to work. This is possible because this file has no native data. It's getting all of it from other files via relationships.

Good luck,

Dan

[bruceR]

I need to make a script that will enable a person to upgrade to a new version without losing any of the old information! I find this really necessary, because I am constantly changing little things on my system, and then when I need to upgrade the version of my database, I have to manually move everything over

Dan's suggestion for using an no-data interface file is a good one. But sooner or later you will need to do an update anyway. Here's how I approach it.

Basic idea: use a self-updating clone file. Close all files. Start the clone. It imports from the old data file, then saves a copy of itself, overwriting the old data file. Example, CloneContacts.fp5 imports from Contacts.fp5 then saves itself as Contacts.fp5.

1. I have a shutdown script in all files that goes to a blank layout and shows all records before closing. This means that I can be sure my auto-import routine below will in fact capture all records.

2. All files have a startup script that first goes to a blank layout, then checks to see if the file is a zero-records clone. It does this with the following IF statement:

If [ (status(CurrentRecordCount) = 0) AND patternCount(status(CurrentFilename), "clone") ]

If the statment is true, it runs a separate self-updater script, saves a copy as noted above, and closes. Your script must also correctly set the next record ID. This requires FileMaker 5.5 or greater. You also need to set the import order to creation order, and NEVER delete fields. If you stop using a field, name it zzDeleted01, make it an unstored text calculation = "DELETED". By not deleting fields you make sure that the import order matching on creation order will work correctly.

Always be sure you have created a backup someplace first before running a self-updater file because it will overwrite your original so it will be gone forever.

[WearsManyHats]

Greetings,

I'm new to the forum but I was looking around for just this kind of information.

Dan, you say you need to set any serial numbers to (max serial number) + 1. I can see the reason for this but I am not aware of how to do this with scripting. My serial number fields are set to "auto enter serial number and increase by 1". I always thought you had to go into "Define Fileds" in order to set this or change the current serial number. Is there a way to do this programmatically?

Thanks,

Bob.

[DanBrill]

Hi Bob,

Welcome aboard. You'd use the 'Set Next Serial Value' script step. It's way at the bottom of the list. You just specify what field you want to renumber and what the value should be.

There's something in my head that says that this step was new to FM ver. 6, but since version 6 is the only one I've ever had, I can't be sure. But if you have an earlier version and can't find it, then I guess I'm right.

Good luck,

Dan

[bruceR]

There's something in my head that says that this step was new to FM ver. 6, but since version 6 is the only one I've ever had, I can't be sure.

As noted in my post, the Set Next Serial Number script step started with version 5.5. Custom Dialog started with version 6.

[WearsManyHats]

Thanks Dan.

I took a look and Lo and Behold, there it is. It seems likely to me that this script step showed up in version 6 but I don't know for sure.

I've been using Filemaker I think since version 4 but only recently considered trying to make a standalone app. This question of upgrading users to a new version of an app is a biggy as far as I can see. As Dan said, one of the problems of storing the data along with the interface and everything else. It seems to me that if Filemaker the company is serious about standalone solutions using Filemaker that they would take a look at making this easier for all involved. Just my opinion...

[WearsManyHats]

Using the tips and ideas that BruceR and Dan mentioned it's clear that previous data can be updated into a new solution.

It seems to me the key problem is how to provide the location of the old data files to the new version of the system so that the data can be imported. I've not used the import script step in a script before or I would know the answer to this question, but I take it you cannot provide the user with a file browsing dialogue from within Filemaker to allow them to indicate where their old files are located?

[kenneth2k1]

Wow! It's good to see that Bruce and Dan have worked out this process by themselves. Ingenuity is man's greatest trait

If you have a couple of boodles, check out UpdateGenie. The initial setup looks complicated, but it's supposed to be easy for the end user.

Ken

[DanBrill]

There is a plug in from Troi that provides this kind of file management, though I've not used it. I get around it with the batch file technique that I outline above, but this would be a windows-only solution.

Dan

[bruceR]

Using the tips and ideas that BruceR and Dan mentioned it's clear that previous data can be updated into a new solution. It seems to me the key problem is how to provide the location of the old data files to the new version of the system so that the data can be imported.

This question was already answered. Please reread the description.

You put the clone in with the old files. The import scripts are set to import from the same folder. CloneContacts.fp5 imports Contacts.fp5 and then the script continues and saves a copy of itself as Contacts.fp5. This overwrites the old file. Then you delete the clone.

[WearsManyHats]

BruceR said:This question was already answered. Please reread the description. You put the clone in with the old files. The import scripts are set to import from the same folder. CloneContacts.fp5 imports Contacts.fp5 and then the script continues and saves a copy of itself as Contacts.fp5. This overwrites the old file. Then you delete the clone.

Yes, but this assumes that you want to delete the old solution file(s). It seems a better practice to me to have a new version in its own directory/folder in case the user, for whatever reason, wants to use the old version of the solution. In that case it would be best to import the old data into the new solution files. I suppose you could have the user copy/duplicate the current solution directory and rename it as "Old Version", then place the new clone file(s) into the existing directory and let the clone files do their thing.

Your method is definitely a good one. By having a defined directory where all files and sub-directories are known by the solution in terms of name and location, scripts can be made not to break. I'm just trying to decide how I want the user to "touch" this upgrade process.