> Firebird and Interbase are aware of which record version is being updated,
> and IMO IBObjects should not permit it to happen.

They are? I'm not sure that is quite the case. They know
that copies are locked, and that other locks cause a
deadlock, but I don't believe that 'currently' the engine is
quite as clever as knowing which 'unlocked' data is being
modified. I may be wrong - of cause.

> This occurs whether RecVersion = True or False and even if
> PessimisticLocking = True.

I have not looked at RecVersion, as I said before, I control
VERSIONING myself with update timestamps.

> I believe that IBObjects should determine if the record version is later
> than a previously committed version of the record and generate an exception,
> or respond to an exception generated by Firebird.
>
> One way to implement this would be to check the transaction number and
> compare it with the current transaction number.

One for others to comment on - I'm still using methods from
pre-IB/FB days ;)

> Another way would be to read the last committed record and check it
> against the values that were read when the current transaction began.

That would be cumbersome, I just check the timestamp of the
record.
The one thing to bear in mind here is "Does it slow down
processing for users who do not need it". The current
capabilites are designed for speed and stability. Adding
another layer of functionality is easy, and most things can
be catered for.

I can see exectly where you are coming from - I've been
there myself, and have a solution that works for me - and
can see what you are proposing could have been useful - but
I am not able to comment on any problems with your solution.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services