Guido Klapperich wrote:

> I have just read the article "Understanding Interbase Transactions" from
> Bill Todd
> http://bdn.borland.com/borcon2004/article/paper/0,1963,32280,00.html
>
> In Chapter "Transaction Options" under Lock Resolution he writes:
> "When your transaction updates an existing row your transaction places a
> row level write lock on that row until the transaction ends. This
> prevents another transaction from updating the same row before your
> transaction either commits or rolls back."

Bill's wrong.

When a transaction inserts, updates, or deletes a record, it creates
a record version with its transaction id in the header. When another
transaction attempts to update or delete the record, it checks the
transaction id in the header of the newest record version. If that
transaction is active (in the case of read committed) or was active
when the current translation started (in the case of snapshot or
concurrency transactions) the operation fails with a deadlock - update
conflict error.

There are no row level locks.

Regards,


Ann