Helen Borrie wrote:

> At 02:13 PM 25/02/2009, Jim Starkey wrote:
> [ ..
> ..
> ..
> ..]
>
> N.I.H. in spades - Classic Wolf! ;-)
>

NIH? As in, "Not Invented here"? That's a pretty peculiar brickbat to
hurl give a) I created it the first place, b) I was applauding Sean for
suggesting a change to fix a problem I originally created. Helen, you
aren't, by any chance, off your meds again?

Anyway, here was the Interbase originally worked and Vulcan restored.
The issue is how to handle a major (and incompatible) change to database
format. Lets assume that an existing engine handles an ODS version
major X and a new, improved engine handles ODS Y. The strategy is as
following:

1. The Y-valve is configured with both engines X and Y.
2. A user of X installs new Firebird version Y. The X engine is
retained (or part of the kit)
3. When application attaches a database, the Y-valve first passed the
attachment to engine Y which can't open it and returns an error.
The Y-valve then tries engine X, which successfully attaches the
database.
4. So, despite the software upgrade, existing databases continue
unchanged.
5. When the user is happy with version Y, he backs up and restores
his database. This creates a new Y version of his database,
leaving both a backup and an intact X version of the database in
case reversion is required.
6. Nothing needs to be changed in the application during the
transition from X to Y. It just works.

This worked very well. Changes to the system tables usually required a
major ODS change (another post on that, later), so this saved our
Interbasian butts more than once.

Borland pretty much screwed up the multiple engine bit when they did
their half-ass implementation of SQL in the Y-valve rather than moving
SQL into the engine where it belonged.

Vulcan restored, cleaned up, and extended the Y-valve architecture into
what became known as the provider architecture. It's still there,
sitting on the shelf.