How are people handling new version updates for Runtime solutions?

[Christensen Design]

I'm just wondering how experienced FM developers are handling the issue of automatically updating a runtime solution after it has been distributed? That is, is it easy/possible to fully automate the import of the user's data from their old copy of the runtime solution into the new version?

I have been playing around with this using the 'Import Records' script step, but I don't seem to be able to fully automate the import such that the Import dialog is never displayed to the user. I don't want the user to ever see the import dialog because I don't want them to be able to change the settings and thus trash their data.

Thanks. John

[rigman]

Hi John,

Your post encouraged me to register in order to share some of my experiences regarding your question.

I've been using the FM developer platform for some time now, beginning with version 4.

One of the best ways that I've dealt with upgrades is by isolating your solution.

What does this mean?

It means basically separating your data from any layouts/script, etc generated in the application.

This means all fields that will store user generated data go into one (or many) files (which I call data files), while the rest of the stuff (your application basically) goes into other files (I call these application modules).

This changes your programming paradigm quite a bit as you need to perform a bit of work defining relationships to link everything in the beginning, however the advantages in my opinion far surpass any initial complexities that this may present (actually it involves just a little different programming than what one can find in the books)

The benefits of this are:

- Transparent application upgrades.

This means that if you modify an application module (for example change a layout or script in it), then bind and send this file to you user for him/her to overwrite the old one, there will be no importing of the records. Therefore data can be instantly accessible.

Under certain circunstances where the application module needs to be able to browse between records (as when using the little notepad icon in the top left), one needs to only recreate the index of the application module (that is, create all associated record identifiers with the data file) and not a complex import process. In other words, there should be a script in the application module that detects whether application and data files match. If they don't it will recreate the exact number of records and import the id number of each record. This process can be completely transparent or one can choose to notify the user that the index needs to be recreated.

-Increased stability in the final solution.

Because data and application are separate files, data structures remain safe should there be a problem at design time. (Actually I decided to explore this type of development since my solution had grown so big (many layouts) that I started to have file corruption issues in version 4.0. Once I segmented the application into modules and kept the data structures isolated those problems were gone forever.

-Super easy data backups

The user needs to backup only the data files, not the whole application! this translates into smaller and faster backups.

-More efficient restores

For the same reasons above... plus, the restore does not replace the application version with an older one contained in the backup! Application remains intact.

I have thought about going into the details on the techniques I use. Perhaps I can start sharing those over these forum... I've also thought about writing some guide or publishing a webpage... but time issues have kept me away.

Hopefully this info will be of help to get you started in this direction, should you decide to do so.

I would also be very interested in finding out what others have done regarding this topic.

cheers,

Robert.

[Vaughan]

Hello Robert

What you describe is called "The Separation Model" or TSM.

Like the Anchor-Buoy method of defining relationships, The Separation Model has its champions in the FMP development community, and it also has it's detractors.

The jury is still out as to whether it's a "best practice" in all circumstances... or indeed any circumstances.

Others will, naturally, disagree. :P

[rigman]

Hi Vaughan,

Glad to learn that others have already taken a similar approach.

Personally I think it is an excellent way to deal with updates, so it may be exactly what the original poster is looking for.

In my case I can comment that back in 2002 I released a major app for the vertical market using such separation methods. Over the years this has allowed for extremely easy front end application changes, including GUI modifications, the addition of new layouts and even the incorporation of new fields. (I say new fields because, back then when the initial fields were defined in the database, extra fields were added just in case the GUI would need to incorporate these for future use.) This has really eased the introduction of the newer versions.

Also, from a technical support perspective the amount of incidents has been extremely low to the point that as of this date we've had zero data losses that we know of. The minor troubles that our clients have experienced so far have been a couple of file corruption issues on the application modules without any damage to the data files whatsoever. Resolving these involved replacing the damaged files with a fresh copy, with no import needed on the user side.

Looking back almost 6 years into it all and I can't think of any other better way to deal with this particular deployment. For me, the peace of mind has been worth many times the extra development spent in the beginning.

[Søren Dyhr]

Beyond that I find neither IWP nor the generation of runtimes, as areas where solutions developers really can cash in on intellectual property. Should it be said that other means exist to getting from version A to B:

http://www.goya.com.au/UpdateManager

Let me gently nod in another direction, if the Goupil ...

FileMaker is a leading worldwide provider of database software for workgroups and individuals.

...GROUPWARE constrains seems too tight a match for entrepreneurial aspirations - this approach might save some of the endless hours honing a solution:

http://newserver.runrev.com/products/related-software/fmpro-migrator-developer/

...instead of starting back from scratch again.

--sd

[Vaughan]

I do contract custom development and in-house work (which is really custom development on a very long contract) and all of my solutions are multi-user hosted with FM Server or occasionally peer-to-peer with FMP.

I can see no benefits to TSM for this kind of work, and only down-sides to the amount of extra development required to make it work. Most of the additional development gets in the way of maintenance since the separation abstraction tends to make things harder not easier.

[Søren Dyhr]

This seems to support my view, further development should be done on a working solution via a handed out IP number, and wet foil wrapped dreams should be taken to another tool, more aimed towards genuine applications such as browsers "looking" and dealing with contents in databases.

TSM is not the most obvious in filemaker development, you do always have to import something anyway! The great question is where should the calc'fields then reside ... interface or datatable? Lookups relational graph should be in which of the files structure?

--sd

[IdealData]

I have done solutions using multiple files, separation model, and integrated single file.

The separation model falls over when you updated the data component, as you must still do an import. Multiple files are worse as you must import for every file/table that has been updated, however that might only affect one or two files.

My preference on small(ish) solutions is single file and use importing to issue updates. The exception here is where large amounts of graphics are involved as they will bloat the file very quickly so they are better off in a separate file.