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

[John Esak]

> all your code with field names, instead of numbers... and I'm not 100%
> sure that "access to fields by name" is a first-class parser
> implementation in filePro:  can you do 'show (row,col) field_name',
> where row, col, and field_name are all the *names* of fields in the
> current record?  And on and on...

Yes, I actually think you could do this.... but don't want to put up the
code right now... it is possible. though.  However, on the fields in maps
chaning thing. When I first released the NEX accounting so long ago, I
thought I came up with a prtetty nifty idea. It had two large fields near
the end of the file. Like this:


    247   NEX expansion            500
    248
    249
    ...
    400  User expansion           500
    401
    402
    403
    ...
    600

Then if I wanted to add a new field for an upgrade release, I would break
out 10 or 15 or 8 of the characters from the reserved NEX expansion field
and move them to the highest allowable number, 399 in this case, and
subtract that nuumber from the 500. So it might become 490 and 10. FilePro
would still see the same number of chars in the map so it all overlayed
correctly no matter how the reserved amount spilled into the reserved empty
fields. And the same thing for the User. They would subtract from their
alotted 500 and put them at field 600 then 599, 598, etc.
this all actually works pretty good. But, what if they need to change the
size of the city field back up at number 12?  My congruency with them is
immediately shot to hell.

So, in this project, I just decided to allow the user to change any damn
field they want  (they're going to do it anyway :-)  and deal with it some
other way.  I'm fast coming to the conclusion that wiht maps, there is NO
way my released map can be congruent with everyone. How could it ever be?
Even on an individual basis as Mark suggested, or as Subversion seems to
suggest it can allow (Walter's reference.) In the final end-run, I can never
be sure what really changed and how in terms of the data type and so forth.
I would have everyone running their own completely individual program ,
period.

So, hoenstly, if the discussion comes out that this is truly impossible,
that's fine. That's a valid  (though disheartening) outcome. I will just
write a foolproof test for a previous version living in the same desired
install directory and if so, refuse to do any automatic updating. Maybe I'll
provide a mehod to pick and choose. At the worst case, I'll provide what I
did in the update letter I just sent out. A complete step-by-step rundown of
every single thing I did to move from version 1.0.1 to 1.0.2 ... then to
1.1.0 and so on... ad infinitum ad nauseum. :-)  I just hate the idea of
asking purchasers to do al lthis manual work. I type so very fast it's no
big deal... some would have big problems with this. Just the few updates
from 1.0.1 to 1.0.2 were huge. :-(

JE