I have just read the article "Understanding Interbase Transactions" from
Bill Todd
http://bdn.borland.com/borcon2004/article/paper/0,1963,32280,00.html

There is one point, that's not clear to me. In Chapter "How Does
Versioning Work?" he writes:
"When a transaction updates a row it looks it its TIP to see if there
are other active transactions with a transaction number lower than its
transaction number. If there are no older transactions that are active
it updates the row. If there are older transactions that are still
active it creates a new version of the row and enters its transaction
number in the new version."

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."

My question is now, how goes versioning and locking together? Or why is
row locking needed, when a transaction creates a new version of a row,
when there is another transaction, that is still working on that row?

The reason why I ask, is that yesterday I got in my app the error:
lock conflict on no wait transaction
deadlock
update conflicts with concurrent update

Why does my app run into a deadlock? I thought, when a row is updated by
an older transaction, the current transaction creates a new version and
goes on.

Regards

Guido