How should filePro-based updates be done with live-data and live-programs involved?

[Fairlight]

John,

Well, this will shift the brunt of the work onto you, but off the users,
but here goes:

1) Track your changes between the versions.  If you make processing changes
to processing table 'abc' in file 'ledger', note that.  Note also any
dependencies.  For instance, if fixing one table somewhere requires a
change elsewhere, keep track of those dependencies.  If it's a processing
table, map (which implies a key change), index., etc...just track what
files are affected.

2) I'd probably go the route that some other tools take, and check all
dependencies beforehand, before a single thing is touched.  Now you can do
what I'm going to suggest for certain changes in segments (ie., "Here's
feature XYZ, do you wish to upgrade this functionality?") and provide
modular dependency checks if you want.  I don't know the nature of your
changes, so I can't say how desirable that is for you, but some people may
want some of the major features without all of them, necessarily.  But
either way, the basic concept comes down to this:

A) Look at what upgrade you're doing, be it a functionality segment, or the
whole package.

B) Look at the files that need changing, as regards processing tables and
maps, specifically.  I'd do a sum or md5sum on each file in the dependency
list for the requested upgrade.  If a single file doesn't match, you warn
the user off with the details of what file breaks the dependency.  They can
always look at the code themselves to see what's affected.  The big
question here is what to do about indexes.  I'm not really conversant with
the index file format, having assiduously avoided it so far, but if there's
a header area somewhere that describes how it's built, you could grab the
header area only and do a sum against just the header areas to see if it's
still the same.  If it is, they shouldn't require a rebuild, right?  (I
hope.)

C) Assuming -all- dependency sum checks pass, upgrade the files pertinent
to the complete upgrade or feature upgrade.

Anything that throws an exception to the dependency list, they should be
notified of the files affected so they can do an impact analysis and bring
things in by hand if needs be.  If they were competant enough to modify it
for their own purposes in the first place, they should be competant enough
to port their changes into the new versions before manually replacing them,
or backport the desired sections of your new code into their existing
code--whichever suits their needs best.

That's all under the option for, "Upgrade my package!"

As for fresh installs, that'd be a separate top-level installation option,
and IMHO should probably also do a check to make sure that the package's
files aren't installed already, just in case someone hits "1" instead of
"2" or the like.  If it detects a version of itself, it should throw up an
error detailing why this isn't such a good idea, please choose the upgrade
option--where you've handled the necessary steps in detail.

That's about the best scenario I have right now off the top of my head.
It's based roughly on how rpm checks dependency lists before doing
-anything- in the way of actual work.  In this case, as with rpm
dependencies (and those often -are- all binary releases, so it's not really
binary vs filePro at all), you're checking actual files more than just
version numbers and packages.

And, unfortunately, you're going to have to have two separate sets of
checksums--one for *nix and one for Windows--since the maps are written
differently.  You'll need an md5 or sum utility for Windows as well, since
I don't think it ships with one.  You might be able to write a routine to
do tht in fP if you don't mind messing about with raw I/O and you have the
math chops for it.

Okay, my idea tank is empty on this for now until I see some feedback from
other people.  Might be able to expand on others' ideas, but I'm dry on my
own, here.

Luck on this.  Sounds like a headache.  :(

mark->
-- 
print("Content-Type: person/now-desceased\n\n");
# The only good MIME is a dead MIME.