There's three cases:

- An ODS change that is safe to allow the prior engine to access.
(Examples: additional system indice, change to a system trigger)
(I had always termed this a "Minor" ODS upgrade.)

- An ODS change that is NOT safe to allow the prior engine to access.
(Examples: Page layout change, additional datatype, bug fix to
index garbage collection that would be re-introduced
if the prior engine touched index pages)
(I had always termed this a "Major" ODS upgrade.)

- An ODS change that is transparent to prior engine if it is unused.
(Example: dtype_sql_date is new in ODS 10, if a database file does
not use dtype_sql_date it's safe for an ODS 9 engine
to use the file. If the file does use dtype_sql_date
it causes the ODS 9 engine to bugcheck)
(Well -- no real term for this -- "New Feature" ? )

For V5 --> V6 there was the change to Generators. Yes, it could have been
coded so existing generators were 32 bit, new generators were 64 bit. But,
for various reasons that are lost in time, it wasn't. (Note: this would be
difficult to document as well - and would give another reason to implement
DROP GENERATOR)

There's 4 upgrade paths:
- No change necessary.
- Automatic conversion made first time new engine touches a file
- A utility program to perform file conversion, specifically invoked
by user.
- Complete backup / restore

For V5 ---> V6, all methods were discussed, and compared to resources
available, risk, etc. Complete backup / restore was selected.

There are 4 downgrade paths:
- No change necessary
- Utility program to downgrade to prior ODS
- Restore from backup files (hopefully made before upgrade)
(either physical or logical)
- Complete backup / restore

To entice user's to actually upgrade, we need to let them know how to
downgrade.
A significant portion of the user base never upgraded from ODS 6 - I don't
recall how this fit into the discussion, but it did.

As I recall the code (aside: one of these days I'll be able to look
before speaking) -- an engine only looks at the Major ODS to decide if
it can access the file. It looks at the Minor ODS to decide if there
are any Minor ODS updates it should apply to the file.

InterBase automatically makes any Minor ODS updates the first time a file
is opened. These are safe, backwards compatible changes.

Dave



-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Monday, May 01, 2000 11:19 AM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Subject: RE: [IB-Architect] Backward compatability with previous
versions of gdb files


At 10:52 AM 5/1/00 -0700, David Schnepper wrote:

>
>Well, first off, it *IS* a major ODS upgrade (64 bit generators). A
>minor ODS change
>does not prevent the prior engine from not touching the file. (If we
>went to ODS 9.1
>any v5.x would still think it could access the file).
>
>An ODS 9.0 to 10.0 update utility would have to update the header page
>to reflect
>ODS 10, and rewrite Generator pages to be 64 bit quantities.
>

I'm not suggestion that we try to rewind history, but I would
like to use this as a case history in anticipation of the next
change to wonder down the pike (and rest assured, folks, it
will come).

Why couldn't the change have been made by bumping the minor version,
which would have prevented the V5 engine from trying to handle the
database file. The V6 engine could easily have handled both
sizes of generators. Why was it necessary to change the major
version number? And why didn't the V6 engine handle the previous
ODS?

Jim Starkey

------------------------------------------------------------------------
GET WHO WANTS TO BE A MILLIONAIRE FREE! GET THE OFFICIAL COMPANION
TO TELEVISION'S HOTTEST GAME SHOW PHENOMENON PLUS 5 MORE BOOKS FOR
$2. Click for details.
http://click.egroups.com/1/3014/3/_/830676/_/957205259/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com