Subject | Re: [IBO] Steps to reproduce possible bad bugs |
---|---|
Author | Raymond Kennington |
Post date | 2003-08-21T04:05:39Z |
Thanks, Alan.
Alan McDonald wrote:
committed by another transaction should not be permitted, since the record
version being updated is earlier than the committed record.
Firebird and Interbase are aware of which record version is being updated,
and IMO IBObjects should not permit it to happen.
This occurs whether RecVersion = True or False and even if
PessimisticLocking = True.
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.
Another way would be to read the last committed record and check it
against the values that were read when the current transaction began.
Raymond Kennington
Programming Solutions
TeamW2W (InfoPower)
Alan McDonald wrote:
>This is what I believe to be erroneous behaviour. Over-writing a record
> > "simultaneous transactions, without any loss of current transaction's
> > updates, but all previously committed values are lost."
>
> minor correction Raymond,...
> only previously committed values which are now being overwritten are lost.
committed by another transaction should not be permitted, since the record
version being updated is earlier than the committed record.
Firebird and Interbase are aware of which record version is being updated,
and IMO IBObjects should not permit it to happen.
This occurs whether RecVersion = True or False and even if
PessimisticLocking = True.
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.
Another way would be to read the last committed record and check it
against the values that were read when the current transaction began.
> There will be a lot of previously committed values which are quite safe..--
> :-)
>
> Alan
Raymond Kennington
Programming Solutions
TeamW2W (InfoPower)