Triggering a script in a runtime that has been moved or renamed

September 23, 200025 yr

Newbies

Say for example, I have distributed a runtime app Version 1.0. Then I have an upgrade version 2.0 that i would like to distribute.

In order to correctily upgrade, Version 2.0 must import ALL RECORDS from Version 1.0.

What is the best way to upgrade this runtime?

I currently have Version 2.0 call for an external script in Version 1.0; SHOW ALL RECORDS, before importing.

This works fine on my hard drive, but if the end user tries it, Version 2.0 can not find the correct file path to Version 1.0, and produces an error.

I am sure this must be a common problem, and hope that one of you FM geniuses (genii?) can shed some light on my woeful situation.

ThX!

September 24, 200025 yr

quote:

Originally posted by silac:

Say for example, I have distributed a runtime app Version 1.0. Then I have an upgrade version 2.0 that i would like to distribute.

In order to correctily upgrade, Version 2.0 must import ALL RECORDS from Version 1.0.

What is the best way to upgrade this runtime?

I currently have Version 2.0 call for an external script in Version 1.0; SHOW ALL RECORDS, before importing.

This works fine on my hard drive, but if the end user tries it, Version 2.0 can not find the correct file path to Version 1.0, and produces an error.

I am sure this must be a common problem, and hope that one of you FM geniuses (genii?) can shed some light on my woeful situation.

ThX!

This is a little late, but I ALWAYS include a Backup/Restore procedure into my solutions. This way you just run the Backup from the old version and run the Restore on the new version, assuming the file structure is the same. If not you can simply have a Restore Previous Version script to accomplish this.

In your case you may need to leave the dialogs displayed in the import, so that the user has to pick the file to import.

------------------

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=

September 24, 200025 yr

Author
Newbies

i am unsure on what you mean with the backup/restore procedure. could you please elaborate?

secondly,i'm not having a problem with the import procedure, but rather trying to trigger an external script in a file that has been relocated. any ideas on this?

thx!

September 25, 200025 yr

quote:

Originally posted by silac:

i am unsure on what you mean with the backup/restore procedure. could you please elaborate?

Backup = Find All Records, Export

Restore = Find All Records, Delete All, Import

Simple procedures really but test the heck out of them before releasing them. Works great for updating software, basically invisible to the user.

------------------

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=

September 26, 200025 yr

quote:

Originally posted by silac:

Say for example, I have distributed a runtime app Version 1.0. Then I have an upgrade version 2.0 that i would like to distribute.

In order to correctily upgrade, Version 2.0 must import ALL RECORDS from Version 1.0.

What is the best way to upgrade this runtime?

I currently have Version 2.0 call for an external script in Version 1.0; SHOW ALL RECORDS, before importing.

This works fine on my hard drive, but if the end user tries it, Version 2.0 can not find the correct file path to Version 1.0, and produces an error.

I am sure this must be a common problem, and hope that one of you FM geniuses (genii?) can shed some light on my woeful situation.

ThX!

Is the difference between your hard drive experience and that of the end user's that yours is working within FileMaker and the end user's is working within a runtime version? If this is the case, it might be that the version 1 that you are trying to call a script in is not part of the files that are bundled with the version 2. I'm just guessing here, because I haven't come across this problem. But that would be what I would try. Bundle the version 1 files in a sub folder of version 2 (since they probably have the same name) and see if it works then.

Chuck

September 26, 200025 yr

Author
Newbies

Thanks. I understand what you mean now by the backup/restore procedures (i thought you meant there was a script named 'backup' or 'restore').

My problem however, might be better explained in this following scenario.

User installs Version 1 on his Desktop. Months later, he gets an upgrade to Version 2, which he decides to install in a different location--- Hard Drive / Applications.

In both versions, there is a script called EXPORT PREPARATION which FINDS ALL RECORDS.

Version 2 has a script called UPGRADE which calls for the EXPORT PREPARATION script from Version 1, then imports the records.

Now, if Version 1 has been renamed or moved while FM PRO is trying to import records, FM PRO will simply ask where the file is, and once located by the user, continue on it's merry way.

BUT, if Version 1 has been renamed or moved, and FM PRO is trying to find Version 1's EXPORT PREPARATION script, then FM PRO will produce a "can't find script" error, and will not ask where the correct file with the script is.

So far, my solution has been to pop up a window warning the user to manually FIND ALL RECORDS in Version 1 before Importing. This works, but seems highly dinky and unprofessional.

Any suggestions?

Thx for all help.

steve

September 26, 200025 yr

quote:

Originally posted by silac:

Thanks. I understand what you mean now by the backup/restore procedures (i thought you meant there was a script named 'backup' or 'restore').

My problem however, might be better explained in this following scenario.

User installs Version 1 on his Desktop. Months later, he gets an upgrade to Version 2, which he decides to install in a different location--- Hard Drive / Applications.

In both versions, there is a script called EXPORT PREPARATION which FINDS ALL RECORDS.

Version 2 has a script called UPGRADE which calls for the EXPORT PREPARATION script from Version 1, then imports the records.

Now, if Version 1 has been renamed or moved while FM PRO is trying to import records, FM PRO will simply ask where the file is, and once located by the user, continue on it's merry way.

BUT, if Version 1 has been renamed or moved, and FM PRO is trying to find Version 1's EXPORT PREPARATION script, then FM PRO will produce a "can't find script" error, and will not ask where the correct file with the script is.

So far, my solution has been to pop up a window warning the user to manually FIND ALL RECORDS in Version 1 before Importing. This works, but seems highly dinky and unprofessional

Basically I would NOT allow the user to keep both v1 and v2 of the solution on the same systems (I can gaurantee that this will cause them further problems) and simply require that they put them into the same folder.

This is where the "Backup/Restore" procedure is very handy since you backup the old version to known filenames in the same folder where you will install the new version. Then you can easily run an upgrade script to import the old data.

If you must allow them to install both versions in different folders, then I would suggest simply making them select the file for import manually.

This is a kludgy and amatuerish way to do it, but you might be stuck in this case.

------------------

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Consultant

Database Resources

mailto:[email protected]

http://www.database-resources.com

=-=-=-=-=-=-=-=-=-=-=-=-=