Importing data into upgraded application

[Pasrandy]

I have a new version of my application that I need to distribute to my customers. In the past, I have successfully used these steps to migrate the data from the previous version:

1. Install new version into a temporary directory

2. Launch new version and execute re-login script step to login to new database with full access privileges.

3. Perform a script in the OLD version database that Finds All Records in all tables. The Perform Script step is the only way I know to open the old version database and it does it with full access privileges since that is how I re-logged into the new database.

4. Import records from each corresponding table in the old database into the new version database (if I don't perform a script in the old database before doing this step, it tries to open with default Guest user access, and that account access doesn't allow records to be exported into the new database).

This method has worked well for several versions, however, in my latest upgrade, when I reach the "Perform Script" step, I get the error message "This file cannot be opened because it does not belong to this solution".

Any hints on what my problem might be? I suspect it might be a binding problem but I can't find anything on the Filemaker site or the forums regarding this. Any help would be GREATLY appreciated.

[IdealData]

I think the binding key is what makes all files part of the same solution, so you're probably right. Did you use the same binding key?

Have you upgraded from FMP7 since you last issue?

[Pasrandy]

Yes, I used the same binding key (I use a very simple number sequence so I won't forget it). And I've been using FM 8.0 since my first version. Thanks for your help though.

[Oldfogey]

Check and doublecheck your file references and their sequence.

I use a similar technique for upgrades and I am nearly crazy with frustration at FMP's handling of imports.

Are you using relative file references? Have you, by any chance, run a test with the two directories not quite in the proper place?

I think I got that same message a while back and am pretty sure it was due to my two solutions having different binding keys. Like you, I knew I wouldn't forget the key but ....

(The really great new feature is that if you edit an importing script while the imported file is not present, the import sequence gets screwed up.)

[Pasrandy]

Great suggestions, and unfortunately I've tried all of them. I played around with the file references to make sure FMP was looking at the right file. And the binding key is the same because I use a saved settings file to bind the solution and I haven't changed it in 10 releases.

I think my only option is to allow exports on all accounts in future releases, which I didn't want to do. This allows a user to buy FMP and import the data into their own database.

It's inconsistent that the import script step always opens the import file with default account access, regardless of how you opened the primary file, unlike the "perform script" step that opens the import file with the account settings of the primary file. But it allows me to use any account to import the data into new versions without having to do a "perform script" first to open the file with administrator access and find all records in all tables (as long as the default user on the import file has "export" privileges).

Like you, I've had ugly experiences with FMP imports. I always double-check my import sequences by opening the runtime database with FMP and verifying that the sequence is set properly.

Thanks for your help.

[Pasrandy]

What an idiot I am! The binding key was my problem, after all. I use two different settings files for creating the runtime app, one for new installs and one for upgrades. The new install settings file had the binding key still set to the date and time

I tested this thoroughly to make sure the binding key was the issue.

The good news is that the upgrade approach is sound and it is a good way to move data from one version of an FM application to another. If anyone needs assistance with this method, I have become an expert so feel free to ask for help!

[Oldfogey]

Glad to hear you solved it. I just cannot understand people making silly mistakes like that!!

(You wouldn't believe this. I was idly thinking about this lot and remembered how I made my blunder. One settings file for initial installs and one for upgrades - with different keys.)

Tell me, how do you manipulate your directories in the update process. i.e. creating the temp and then, presumably, renaming it? Do you do anything to get rid of the old one?

Edited January 1, 2007 by Guest
Memory improved.

[Pasrandy]

I use "trigger" files, ones that are created by the Install program (I use Inno compiler to generate my setup files, and it works great and it's free - www.jrsoftware.org). Anyway, the opening script in my application looks for these trigger files and depending on what file is present, it performs different actions (upgrade, etc.). I also use the Troi file plug-in a lot to manipulate and look for files external to the application.

For the upgrade, I use a DOS script to copy all the new install files into a temporary directory and then it launches the application. When the app sees the trigger file, it imports all data from the existing database. If everything goes as planned, it deletes the first trigger file and creates another one with a different name (this trigger file tells the DOS script that the upgrade was successful so the script renames the existing directory to "application old" and moves (renames) the temporary directory to the live application directory. The trigger file can also be used when the application is launched the first time after the upgrade to tell the user that the upgrade was successful (or whatever else you want to do).

This works very well and has been a great way to install an upgrade without doing anything to the original application until the upgrade is complete and successful.

Hope this helps!

[Oldfogey]

Sure does give me some more ideas! Thanks for that response.

[MSPJ]

Hi - I'd like to take you up on your offer of help on this topic - upgrading an app in fm. Is the offer still open?

THanks,

Michael