Updating a Runtime Solution

[Dayanden]

Updating a Runtime Solution

I have been lurking and searching multiple forums off and on for the last year in an attempt to find an example on how best to accomplish the updating of a runtime solution. With in the next month I am preparing to release the first phase of my project but I want to make sure that I have a method for updating before I begin.

Quick description:

I am developing a student / billing / attendance / and a lot more database… This is an ongoing project that will be distributed as each portion reaches completion. I am still adding fields and tables so the separation model will not work at this point. Due to its nature existing tables are continuing to get new fields added to them.

I have developed a script for importing data from previous releases but this is dependent on having the full Filemaker. I am currently unclear on how to import information from a runtime program. All my users will be working in the runtime so I need a method to import so that they will not have to enter everything from scratch upon upgrading (This will not even be possible due to the large amount of information being tracked and how it functions).

I have seen mention of a method of renaming some of the runtime files. However I have not seen what files need renaming and if you simply need the Import command once they have been renamed. My other concern is that the data base is password protected and right now when importing I have to enter a password for each and every table. I am sure that this is just a pipe dream but I’m going to ask anyways…. Is there a way to import all tables with a single import command or a way to set the password to automatically use on each import after the first?

If on of you FMP Gurus out there could give me a somewhat detailed example on how to this I would be eternally in your debt.

That or if this information is already posted somewhere I will call myself nasty names for taking up your valuable time. (Give me a link though)

[bcooney]

I have developed a script for importing data from previous releases but this is dependent on having the full Filemaker.

Why's that? Runtimes can import data.

I have developed a commercial runtime application. Here's how I do updates. I created an Upgrade Wizard routine. It's called in my open script. If the user does not have any patient records (it's a medical app.) then the Upgrade Wizard routine starts, otherwise they go to the Main Menu.

I distribute the app using an installer, so I have a reasonable confidence that I know the path to the "old" file, and of course I know its name. So, I have the Wizard try to find the old file and insert it into a container field (field must be on layout for Insert File to work). If that fails, then the Insert File dialog is called. The user then finds the old file themselves. Since I know the correct file name, I validate the name of the file that they select to confirm it's the correct file. Once in the container field, I parse out the path to the file and store it in $SourceFile for use in the import script steps.

If all that works, then it's on to the Import Script. As you've found out, you'll be prompted for a password for each import script step. My system is set to autologin with a user account (that allows export, btw). So, that's how I got around that issue. Maybe you could be clever and use the Relogin script step? Remember, if a file is open, then you'll import only found sets, so watch out for that (do Show Alls). Also remember to Set Next Serial after each import.

hth

[Dayanden]

I like what you have for locating the old file.

I also don’t think I articulated myself correctly.

I know that runtimes can import data I just need to figure out how to import data from a runtime.

When I said I had an import script I meant that it will import from a filemaker file (*.fmp7) not a runtime file.

When I try to import from a runtime it does not show any files and when I select the *.* then select the files in the runtime file it is kicking back errors. Perhaps my knowledge of the file types (*.filetype) is not up to par. I think I am missing something simple which makes this more frustrating. I think I need to do a file but I am failing to understand the correct process for this.

This is what I am looking for Bcooney. Can you bring me up to speed on this part of the process?

Thanks

[bcooney]

OK. There's no need to convert. When you write your import script, you should manually browse to a source file. This will give you the left-hand side of the import mapping. However, the first path it should check is $SourceFile.

When the runtime runs the import it'll find the $SourceFile and import it as if it was a .fp7 file.

[Dayanden]

Thanks Bcooney,

For some reason I must not have been directing the import to the *.USR file.

:doah:

[bcooney]

That's why I like to insert the source file into a container as a reference, and then parse the path. If you wanted to, you can validate the filename, as I do, after the user imports the source file. So, if they select the .exe file, you can halt the script or whatever.

[iamtechman]

With your install routine, how do you prevent the installer from writing over the "old file" and yet having it the same name as the original file so the user clicks on it to run your Wizard. Any help would be greatly appreciated. :

[bcooney]

I have a main folder for the application, and within that folder subfolders for each version that I send, so I don't overwrite anything.

I really should add a delete old folder routine at the end of the upgrade Wizard, but I'm afraid to. What if the import fails? I want the user to have their "old" version. I do tell them in the instructions that they can archive the old version once they're happy within the upgrade.

[Ersen Kavak]

Thx for this clear explanation:

Following did not work for me though during a script which will update data from 20 tables either between runtimes or between a runtime and normal FP7 file (to my understanding this does not matter, runtime behaves mostly as a single-computer version Filemaker Pro Software);

1 - I dont want to set autologin on for a particular account name because mine is a multi-user system (may be I am missing something). Therefore, I could not manage to escape from the multiple username and password prompting problem; which is quite annoying for 20 tables; i.e 20 imports :

2 - The left hand side of the Import dialog box (the source file) does not display anything because I take the filename into a $filename variable by prompting the user to address the source file and storing a reference to that file. And finally copying that reference to the $filename variable. Therefore, I guess, Filemaker realizes only one Table from the source file and does not bother to search for a matching Table name during the import. This results in no import at 19 tables, but only 1 table. So, do I need to make the user browse the tables one by one ? This will not be proffesional at all.

I have been searching for the solution for a long time, but I am unfortunately still where I have started : Any help to the above questions would really be aprreciated.

Regards

[bcooney]

Ersen,

Your import script needs to go to each table layout and import. So if you end up with a chain of go to layout, import script steps.

PS: Oh and "mine is a multi-user system", huh? Runtimes are, by definition, single-user systems.

Edited July 28, 2009 by Guest

[Ersen Kavak]

I am indeed going to the corresponding layout for different tables. I am attaching the snapshot of the script and also snapshot of the Import Script Step 'Specify Import Order' dialog box, which does not display any source field to select the Table name in the source file (which was prompted by the user and assigned by us to a variable name)

And, runtime solutions, to my knowledge and experience, can be multiple user (single-computer) and multiple priviliges. At least, I am using it that way. But, this is not the primary concern currently, as a workout can be fixed, probably.

I have checked your very nice example in the importing&exporting part of the forum at http://fmforums.com/forum/showtopic.php?tid/209924/post/335152/hl/runtime/fromsearch/1/#335152

In your example, AT MY COMPUTER (maybe only my computer); the INVLi table does not import the data from v1, where as other 2 tables (invoices and people) do. And this pattern does not change, when I alter the 'Arrange By' option in the 'Specify Import Order' of import script step (see attached image) for any of the tables.

This currently looks like an unsystematic thing to me, but maybe it is a late time to think :

I am running FM 8.5 Advanced V0.1. Maybe, that is the thing...

Regards and Thx for the discussion and nice examples again

[bcooney]

What I've noticed is that I use $SourceFilePath which is set to GetValue( GetAsText( _SYS::gImportFile ); ValueCount (GetAsText( _SYS::gImportFile ))).

You want the path, the second value in the container.

You are using $filename.

[Ersen Kavak]

Thanx again for the notification, it helped.

However, it does not solve the problem. It does not matter what you use, actually:) Filemaker can locate the file...

But, it cannot simply match the Table names to each other in two different files when the file name is introduced as a variable.

Right now, I am kind of stuck with this hoping that this is a bug about my version :

[bcooney]

"But, it cannot simply match the Table names to each other in two different files when the file name is introduced as a variable."

Right. This is NOT what FM needs. In the Import path, you must give FM a full path to the file, not just the filename. If you follow my example, you will see that $SourceFilePath is what is in the Import script step.

Also, you must be on a layout based on the target import table before calling Import.

[Ersen Kavak]

$filename holds the following during the script

filewin:/C:/Documents and Settings/Administrator/Belgelerim/shareyourscience_v1beta/shareyourscience_v1.fp7

and script accesses the file and opens it and asks for username&pwd

so $filename already holds the file path, it is just the name of the variable (my misconceptualizition :

[swissguy]

HI

I just added a post in an other group as this issue (update runtime) was discussed there.

Here is the link

http://fmforums.com/forum/showtopic.php?tid/209924/

Sorry if this was the wrong place to place my post.

Peter from Switzerland