Distributing updates to an application

[jeffshap]

I am developing and application that has 9 files and contains about 35 tables. Does anyone have any tricks on how I can easily distribute updates on this application?

Edited October 17, 2006 by Guest

[John Mark Osborne]

The difficulty is importing the customer data into the new version of your solution. Most developers separate the data and the interface to make this very easy in most scenarios. In other words, use one file for the layouts and scripts and, as many other files as you want for storing data. In this way, you can update the interface file with a new layout or script and not have to import the data. Yes, sometimes you need to add a field into one of the data files and then you have to import the existing customer data through a series of scripts. Are there any tricks? Tricks conjure up the idea of something simple and the process is not simple. You have to walk the user through the process of importing into one or more files using scripts to ease the difficulty. With plug-ins like the Troi File plug-in < http://www.troi.com/ > and techniques like dynamically specifying a path using a script variable < http://www.filemakerpros.com/SAVEDYN.zip > you can make the process easier.

[jeffshap]

I am not sure I can seperate the data from the interface in my situation.

If I want to distribute runtimes , don't I have to build them all at the same time from the same application?

[John Mark Osborne]

I'm not sure I understand your question about runtimes.

[datakeeper]

Jeff,

Here is one solution I have used a number of times to distribute a new "version" of existing software. It appears very professional to the users and has worked very well. I distribute all software over the Internet and my users simply run the installer and run one command.

First you need a script in your new version called "Run Special Command". This script shows up in your Scripts menu (I rename it Tools)and can be chosen by a user who is then asked to enter in the special command. My script contains an entire list of special commands I might want my user to run once in awhile and one of the commands is "GetData". My "GetData" command goes out and opens their old version which was renamed by my installer when the new version was installed and imports the data. I have of course a whole list of scripts for each file and table that imports every field from the old version into every field in the new. When the process is completed, it politely tells them "Your data was imported from a previous version. Please print a new manual....."

Other examples of commands you might want to script and have available for the "Run special Command": Empty, RestartID, etc.

You could skip the "Run special Command" step all together and just have your file look for the previous version data files and if found import.

Hope this helps.

[jeffshap]

I certainly appreciate the help on this. I am new to FMP but not a new to the software development world. I have abstracted my reports and some scripts but I found I had difficulty abstracting everything. Since, my early stages of development still require updates to the datastructures the abstraction doesn't mean I won't have to write an update for each table. I was hoping there was something like "updategenie" still around that would help.

More specifically, the problem I have is with the runtime. When I try creating a runtime (with the same bindkey) that will run the update I get the message that the file is "Damaged" or "not part of the application". When I make the update as part of the new application, it asks me to re-login to each "old copy of the data" for every table that I am importing. What am I missing?

[datakeeper]

If you log in to the new file using a username and password that is available in the old one, then you shouldn't be asked for a password. I have used a relogin script before that executes in the import script that relogs me in as a user that is present in the old system (a dummy user used only for this process) and then performs the import.

[jeffshap]

So you could save me some time if I can ask just a couple more questions.

Everything works just as you say unless I try this in a "RUNTIME" version of the program. My update process is as follows:

-save compacted copies of the live data files to a subdirectory called compact

-Copy the new program and databases to the live data directory

-Open the new databases and import each table from the files under compact

All files are setup with a "System Manager" account and I still have to re-login each time.

I have tried this with/without adding a file reference to the compact files.

Should this work?

[stefanshotton]

Wouldnt it be useful if filemaker actually made dtabase changes available by script.

ie.

rename field in table

Add field to table

Chnage calculation

etc.

Just like you are able to do with mysql/sql commands

[pjdodd]

jeffshap

Your technique should work providing that your account(s) on BOTH versions of your solution (old and new) have the export privildge set to on. I ran into problems and discovered when "marking" the old version that the account used couldn't export.

The process is scriptable using Scriptmaker (and tedious to do). If you were on a Mac a little lazy applescript could help you shift files around. I'm not PC bashing (well, not today) but pointing out there is a way to achieve what you want to.

It would be even more useful if there were a "simple" Update command from application menu that could be directed to older databases and import the data correspondingly. May be by version 15 or 16 Filemaker might actually code this.

Edited November 28, 2006 by Guest
bad spelling