Topic: How should filePro-based programs be upgraded?

[John Esak]

Hello all,

I would like to pose a simple question for discussion. It has lots of ramifications though, and no immediately visible simple answer. People who have bought (and are buying) the Survivor Accounting package are going to have a discussion about this some time soon in the FP Room, but I mentioned to them that I would put a thread up here (and the filePro Forum) to get things started and get some ideas from those who don't have the program and won't be buying it but still have thoughts on the subject.

"What is the best way for me to release update, upgrades (i.e., new versions) of the Survivor Accounting CD?"

The problem is this. The accounting system I'm providing is NOT a binary program. I can't simply put out Version 2.0 and say put this over the top of what you already have. Since the system is written entirely in filePro and the source code is provided so that it can be modified to suit individual needs, the standard way of releasing new versions is impossible. Not only can people change/modify the source code (processing tables, maps, screens, etc.), but they obviously *use* the programs so their data is unique with its own key files, indexes, selsets, etc.

So, if I release a CD with new code in the processing tables, or new/changed field in the map, how can it be done so no one accidentally destroys their live/working system?

A couple of basic parameters for the discussion that are immutable, are as follows. The CD must be usable a "new" install for people who are buying the program from scratch. In other words, they are buying in at Version 2.7 and they have never had the programs working before. No problem for them. But, the CD has to have its keys and indexes ready to go. Actually, I arrange it so the critical configuration key is filled on-the-fly when you begin configuring the system, and all the other keys are empty. However, the indexes (which also are created on the fly) do have to have a pre-determined size and shape.

In the past, on other systems, I've just released updates with no keys, not even a zero length one (that would be disastrous). However, I was able to assume (I hate that word) that the maps would not have been changed by the user. With the accounting, I can not be sure of that at all. In fact, I would say most people do (will) adjust some of the maps to their taste. (Hopefully, they won't change crucial keys with indexes and so on, but you never know). If they are competent they can certainly change anything they want.

How do I put the upgrades out then? Changing the key to something like newkey and the indexes to newindex.A, newindex.B... and then providing a script that moves them into place on demand has some merit, but which ones would the script move? Ask a question about each file?  That's odious.

Maybe put two completely different installs on the CD, one for brand new users that goes on complete and as it does now... and one which is for people who already have the system up and running. This install would have *no* keys and *no indexes. Not bad... but, what about maps? Have a "newmap" also?, and only move it into place if requested? There are lots of maps... this is also pretty onerous if not odious.

Anyway, you are getting the idea. In the 1.1.0 CD I'm sending out tomorrow (yes, we jumped right over 1.0.2 :-)) I do not have anything other than the full new version CD... and NO protection of any kind if someone installs it over their old system. If they do, anything they had will be replaced.  I'm just going to issue brightly colored and HUGE warnings about destroying your live data... and suggesting that people copy the things they want very judiciously. It's the only way I can think of at present, and indeed, it just may be the only sane thing to do.  However, I feel I would like to provide something foolproof, and I'm up for doing a reasonable amount of work on it...  What I don't want is something SO work-intensive for the person doing the upgrading. I really don't want to show them each map, each processing table... just to see if it should be upgraded or not. Yes, I can test old formats against new and know which have been changed.... but this means I have to keep all the previous levels on the CD as well as the new ones... and it is just too cumbersome an idea to implement.

Kinda makes me wonder why I didn't just write some "binary" thing everybody wants and not get myself into such situations. :-)  But I've been wondering this for my whole life... and some things just won't ever change. Besides, the completely generic accounting base in filePro is such a good thing and has been needed for so long, somebody had to do it.

Let's have at it... all good ideas welcome of course. Obviously, this is about my product, but it is a core problem for filePro-based products, so I feel it belongs in open non-OT discussion. I would appreciate it SO much if we can do this one with just our brains... and no flames... not even any flickers. If you're not interested, just press D. Thanks.

John

P.S. By the way, I did put up (in a private email note to owners of the accounting package) a tentative date/time for this discussion in the FP room of either 9am Wednesday, or 6pm Wednesday (EDT) next week. I'll post up whatever is agreed upon as it happens.