Upgrading a Runtime Solution

[Maus]

Hi,

 

 

I'm creating a runtime solution on a Mac but want to be able to send out upgrades in the future, and to non-tech type people (in other words, this needs to be pretty simple on their end). The direction I'm currently going in is to run an external script in the old version (from the upgrade) to export each table to a specific file in the old version's folder (which I have instructed the user to place on the desktop, with the upgrade), then to import using the script in the upgrade.

 

 

Is this the best way to proceed? Does anyone have a better suggestion? I'm encountering a couple of problems already with this:

1. global fields cannot be imported as globals

2. container fields cannot be imported this way (and my solution is filled with 'em!)

3. It really relies on the user getting everything right (both the old and new versions on the desktop, following the directions to use the proper script, etc.) -- again, this is designed for very low-tech type folks, and my fear is that there's too much room for user error.

 

 

Is there any way to deal with these issues? I don't have the money (or technical know-how really) to invest in packaging everything together into an installer (i.e., VISE or the like).

 

 

Any help would be GREATLY appreciated.

 

 

Thanks!

 

 

--Myles

[Josh Ormond]

Hey Myles,

Definitely an often asked question. It is very doable, even for free...it will just take you some time and testing to perfect it to make it easy for your users.

 

1. Transferring data.

If possible, the data-separation model can be very beneficial here. If your updates/changes don't involve structure changes, then you can just rebind the files and replace just the interface file. No data transport needed.

 

If you definitely need to transport the data into the new files (for several legit reasons...like a new file format, etc), take a look at FileMaker's help article. It gives you the framework for what you need to do. http://www.filemaker.com/11help/html/fmpa_tools.24.17.html

 

2. Packaging the files.

This is mildly trickier, but still doable. There are a couple very decent (and free) package/installer creators. For Windows, Inno Setup is a very popular choice. Gives you a ton of options. I've used this one a little myself with some test stuff. Takes a little getting used to, but very useful tool to have in your tool kit. For Mac, I believe the package creator (Package Maker???) is part of the OS. But one of the Mac boys will have to confirm that for me. My Mac is older, and currently still in the box from our recent move.

 

Test it with your system until it feels smooth. Then try pushing it out using someone you know that is less tech-savy. See what they have trouble with. Correct accordingly, then push out to others.

[AHunter3]

Dating back to the FileMaker Pro 4.0 era, I've handled updates by an entirely scripted process. It's decently idiot-proof for your end users. Here's a modern description of the general process:

 

a) First write a script (or one for each file in a multi-file solution) that goes to a layout passed to that script as a script parameter. Do a Show All Records. Set a global field to Get (foundcount). Then loop through the records setting a $Variable to $Variable & Left ("¶", Length ($Variable)) & Get Field (Get (LayoutTableName) & "::Serial Number". Go to Record [Next, Exit After Last], end Loop.

 

This assumes that each table has a field named "Serial Number"; it could be "__PK_TableName" where TableName is the name of that table or any other naming scheme by which the name of your primary key field can be abstracted from Get() functions.

 

Anyway at the end of the loop you've got a stack of unique record IDs which are the primary keyfields of the table to which the script parameter sent this script. Set another global field to the $Variable.

 

 

b) Now if you've got any CUSTOM value lists that your solution lets end users modify, write a second script (per each file that has such VLs) that sets a global text field to ValueListItems (Get(FileName); Get(ScriptParameter) ) so that for each script parameter passed to it it will fill the global with the values of the value list of that same name.

 

 

=====

 

 

c) NOW duplicate your file(s). Change the names of the duplicates to FileName_Old.fp7. In your original files create External File References to each of these (in a multi-file solution each file needs an external reference to Itself_Old.fp7, plus one file, which I'll refer to as your Main file, needs to have external references to all of them).

 

d) Establish for each file in your solution relationships of the form YourTable::Serial Number = YourTable OLD::Serial Number

 

e) Now write a script that methodically goes to a layout for each table, does a Show All Records, Delete All Record [no dialog], then calls the script described in a) above, handing it as a script parameter the name of this layout. Then it should snag the value in the global field in the Old file indicating record count. Write it to a log table, like "Preparing to Import " & YourFile_OLD::g.GlobalFoundCount& "records from previous version " & Get(CurrentHostTimeStamp). Then loop through making new records, setting the primary keyfield to the next record in the stack of Serial Numbers that are stacked in the second global field in the OLD file. You can use GetValue (OLDFileTable::g.SerialNumberStack; Get(RecordNumber) ) since you started off with a dead-empty table. Then populate all the remaining fields using Set Field [YourTable::Field; YourTable OLD::Field] nomenclature. If you have added fields since previous version you can enter default values; if you've modified how you store this or that bit of data you can accomodate that at this point, too. End this loop of new-record-making when Get(RecordNumber) = ValueCount (OLDFileTable::g.SerialNumberStack). Then script writes out to your log table something like "Import Complete " & Get(Foundcount) & " " & Get(CurrentHostTimeStamp) so you can error-check later, and then onwards to the next layout / table combo.

 

f) If you have the custom value lists as described in b), you have to invoke the script command "Open Manage Value Lists" and instruct the user as to which custom value list to open; that the user should select all and PASTE for each one. Then you loop through calling the script n the OLD file described in b) then set a global field in the current file to OLDFileTable::g.GlobalVLContents then Copy [select] your field (which you've placed on a utility layout —— you can open a new window and go to that layout then close it when done) and then run the Open Manage Value Lists command at that point, which pauses the script until the end user edits the VL and exits the Manage Value Lists environment. Continue for each relevant value list repeating the process.

 

g) Finally, write a script that users Send Event or Perform AppleScript, depending on Get (SystemPlatform), to rename all files in folder at Get (DesktopPath) or specified folder elsewhere & "YourSolutionName" by appending "_Old" to the filename. You know your own files' names so you can issue separate commands for each original file. So your instrux to your end user is to move soution in YourSolutionName to their Desktop (or pick elsewhere and specify where that is) and run the Upgrade command in the Installer file, which sits on the CD. The Upgrade command runs the renamer then instructs the user to hit continue and the Installer spits out the new files, exporting them from container fields to Get (DesktopPath) & "YourSolutionName/" & EachFileName.fp7. Then it opens them and runs the script described in e) and, where applicable, the one described in f). Then it closes all files except the installer running the master script and that file can tell the OS, via Send Event or Perform AppleScript, to discard each FileName_OLD. Done!

[JohnCarpmael]

Thank you AHunter3 - that is incredibly helpful.

 

I think I have understood the system that you have described for upgrading existing runtimes. I will try applying your ideas to the runtime I am currently designing.

 

I wonder whether you could clarify how to implement the installer.

 

It sounded to me as though you were suggesting that one might use a separate FileMaker runtime to act as an installer. This runtime (runtime A) would contain the renamer script and as you say would 'spit out the new files, exporting them from container fields'.

 

So would I create my own solution runtime (runtime B) and then place them within the container fields of runtime A, and send runtime A to my users ?

 

Any help in clarifying this part of your scheme would be really helpful.

 

I am using FileMaker Pro 12 Advanced.

 

Many thanks

 

John

[AHunter3]

So would I create my own solution runtime (runtime B) and then place them within the container fields of runtime A, and send runtime A to my users ?

 

Yes, exactly. Runtime A replaces a commercial installer and has a script to rename the old solutions files and has no other purpose. Runtime B is what your end users paid for.

[JohnCarpmael]

Thank you. That is so helpful !

 

But am I right in thinking that with Windows I will still need to use a conventional installer to correctly place the files the first time around.

 

All the best

 

John

[AHunter3]

I don't see why you'd need a conventional installer, but I don't spend much of my time in Windows. Is it a file ownership & permissions issue, or a registry issue, or what?

[JohnCarpmael]

Mainly the problem is one of ignorance on my part ! In the FM Pro 12 Advanced Developers Guide, on page 12 it says:

 

Note Windows: The proper method for distributing Runtime solutions (including the executable) is to use Installer software. This software must install components in the proper location in the Windows filesystem and provide an uninstall capability. See the Microsoft website for information about the location of installed files as well as location restrictions.

 

I am much more familiar with Mac, myself. Maybe I'm making a bit of a meal out of it ! When distributing to Mac users I'd simply place the runtime in the Documents Folder so that its easy for them to backup. But with Windows, I'm not certain where it needs to go.