Maintaining / upgrading installed programs

[Simon Bowler]

I would be very interested to hear how experienced FM developers deal with maintenance and upgrades of installed programs. Without a distinct "Routines Library" I guess this means exporting data from the old version and reimporting to the new. Do people use a script for this?

Reference has been made in these posts to designing the database such that data and routines are separate though I didn't understand this.

Thanks

Simon Bowler

In_Gj.zip

[dynaflash]

In lieu of something better. I have written a script which will automatically export all records into a text delimited file. Then when I write the updated program, which is empy of records. I write a script which will, upon detecting there are no records. Automatically import the text files. Not very elegant but seems to work. Also, depending on size. You can set the export to a floppy drive for backup storage and have a script be able to re -import the text files. nice if your solution becomes unstable ie. user force quits while using your app and the databases become corrupted. You have a delimited text file for backup. Obviously stops short at container fields with multi - media though.

Any better Idea would be welcome.

[Simon Bowler]

Thanks Dynaflash - your solution seems useful.

Perhaps this section of the Forum is seldom visited - it seems to me this issue is a pretty basic one in Filemaker - yours is the first reply in nearly 2 months.

Id still be interested in alternate approaches or more general thoughts on the issue

[kraftyman]

I'm using something rather more complicated. Suppose the original file is A1, the update is A2.

Suppose also that the data structure is same, and you are not using a sequential primary key (bad move - too limiting)

User downloads update into an update folder.

A2Script copies all data from A1 into A2

A2Script then switches to A1

A1Script saves copy of A1 file into backup folder.

A1Script closes A1 and switches back to A2

A2Script saves copy of file as A1's name in the original folder.

A2Script exits and closes A2.

It is a bit complicated to set up, because the scipt steps are named identically, and the backup/update folders need to be created before the solution is bound. The user could also get a bit confused,so that you might have to launch the right database from within the installer.

[Fitch]

One method I've tried is to send along an extra "Setup" database that displays instructions for the user and has buttons that call the external scripts in the target file(s). That way, the scripts in the target files can remain safely tucked away.

[dynaflash]

Here is another thing, and I bring this up because I agree, this subject doesnt seem to be covered very well and I have searched for the answer myself.

I currently use developer 4.0. I have been afraid to use "Save a Copy" and have used Tab delimited text files instead, because I have been concerned with future FM Developer upgrades in which my new bound upgrades will not work with the original 4.0 files which are already implemented in the field. In other words, delimited text files are extremely universal. In fact, future upgrades could include importing my solutions data into other programs. This is all possible through text delimited files.

I suggest that whatever you decide to do. Before distributing your solution. Include an Export script in each file which will export that files records in a delimited text file. If your not sure you will ever use it, just dont have it attached to anything. Its sort of a hidden backdoor so in the future, you always have a way to get at the data which the user has spent countless hours inputing. You can always call the script remotely in future updates through the update program.

Simon - This entire subject has not been covered as well as it should be since it is arguably the biggest trap you can fall into if your solution is widely received and implemented. Any other problem you could have can be solved with an update (fixed) program. But, if you cant update your customers original program, you have serious issues! Customers can put up with a crappy layout, or an ill behaving window (ie. windows pulldown menu's!) BUT, if you cant update their solution without them having to re-enter all of their data, again, they will go crazy!

Sigh! now if filemaker would only allow export in a pipe delimited file! - the big problem with the delimiters filemaker allows is they can be found in a field, which would then create a field separation. ie. a tab in a text field.

Anyway, lets hear more about this subject!

[Steven H. Blackwell]

>Sigh! now if filemaker would only allow export in >a pipe delimited file! - the big problem with the >delimiters filemaker

>allows is they can be found in a field, which >would then create a field separation. ie. a tab in >a text field.

I believe you will find that on a tab delimited export such characters are converted. Tabs are converted to VTABS and paragraphs returns are alos converted.

HTH

Old Advance Man

[dynaflash]

OAM - thanks for the clarification! I have only tried my updating process under test conditions where I avoided the TAB in a text field. I didnt realize that FIlemaker would use a VTAB instead of just a tab like you get when you hit the tab key.

If this is correct then I am even more excited about this system.

Thanks