--- In ib-support@y..., "Wilson, Fred" <fred.wilson@b...> wrote:

> - TxnA starts a transaction
> - TxnB starts a transaction
> - TxnB updates a single row in the table but doesn't commit
> - TxnA updates the same row in the same table and the excute fails

with a

> "deadlock". We would have expected the second person that calls

commit to

> fail, not to fail at execution time. It doesn't matter who start

their

> transaction first, the first one to actually "execute" the SQL

statement

> wins (even without committing).
> What are we missing. This doesn't seem "correct"

No, that seems right to me, Fred. I don't have an in-depth
understanding of transactions, but as soon as anyone starts to update
a record (via uncommitted sql or an unposted db-linked control)
nobody else should be able to edit it *until* the first person elects
to commit or rollback. Possibly what you mean is the duration of the
transactions. Person 1's transaction could be in limbo for minutes
because they are working with a form that opens a transaction and
waits for the user to hit a 'commit' button, whereas person 2 could
have a form that only starts/executes/commits the update transaction
when that user hits the 'commit' button. This is my understanding of
the situation (corrections appreciated).

Regards,
Andrew Ferguson