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

[Jay R. Ashworth]

On Wed, Apr 04, 2007 at 08:39:05AM -0400, John Esak wrote:
> "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.

Yup.  That's the problem.

> 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.

I'm fairly involved with the MythTV and Rivendell projects on Linux,
both of which have the same characteristic that makes this so
troublesome here: they're based on DBMS backends.  In those 2 cases,
the issue can be even more complicated, because the backend DB engine
might be shared.

The compensating advantage is that those two are based on SQL
engines... which means a) that it's possible to programmatically add
fields to the tables from a script and b) that it doesn't really matter
where you put those fields, since they're referred to by name, not field
number.

Neither of those things is true for a filePro based app.

The former, I'm not sure I see any "official" way around -- a faint
memory suggests that there may be some way to trick ddefine into doing
a restructure externally (or perhaps it's semi-official; autoshuf?).

The latter, though, is worse: unless you're willing to tell your
clients, the resellers of your package "do not add fields to my tables;
if you need extra fields, create a one-to-one table of your own, and
join it in", then they're going to put those fields at the end of the
tables you shipped them... and I see no way -- logically, not just
implementation-wise -- to work around that.  Short, that is, of writing
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...

And, likely you *didn't* already do it that way, so...

Nope; you're right: updating filePro apps -- especially when they're
wholesale to people who bought them *precisely because* they could
extend them -- is a miserable thing to contemplate.

Sorry I can't make any good, clean suggestions about solutions, but
hopefully, I've delineated the problems a little more clearly.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274