How should filePro-based updates be done with live-data and live-programs involved?
Nancy Palmquist
nlp at vss3.com
Wed Apr 4 11:59:37 PDT 2007
John Esak wrote:
> 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.
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
John,
My suggestion might be to install it in a different subfolder just like
a full new install.
/john110/filepro
/john111/filepro
/john/112/filepro
/appl/fp - filepro executables
Like that. Then the user can pick and choose from the new processes and
meld them into the old if they want.
Give them a start script that goes to the right version.
That way they can compare processing or just review the issues and
manage the needs as they choose.
Nancy
--
Nancy Palmquist MOS & filePro Training Available
Virtual Software Systems Web Based Training and Consulting
PHONE: (412) 835-9417 Web site: http://www.vss3.com
More information about the Filepro-list
mailing list