At 10:31 AM 07-12-00 +1100, you wrote:

> >(4) Any other issues related to migration

I forgot to mention that IB uses a totally different architecture for
record versioning - referred to as Multi-generational. This mean that
client code does not set, retrieve or in any way specifically manipulate
locking. Instead, transactions "reserve" their access policy by requesting
a specific combination of isolation level, record version and "wait"
strategy for conflict resolution. Table reserving is also available for
extreme isolation.

The database maintains locks internally, according to its current knowledge
of the age and activity of transactions. (This also means that, if
somebody trips over the server's power cord, there are no user lock files
to be trashed). A connection can be configured to force writes to the
database. These features combine to make it so that, when powered up
again, the server can simply pick up where it was interrupted and
continue. (There's a little more to than that, however, if transactions
across the boundaries of a single database were interrupted...)

H.
All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________