Vlad Horsun wrote:

> Deadlocks in lock manager and deadlocks you see in error messages
> are two very different things. The most common 'deadlock' message is
>
> isc_update_conflict : update conflicts with concurrent update
>
> where isc_update_conflict is secondary error code (primary is confusing
> isc_deadlock). Here we trying to update record which is already updated
> by another not committed transaction. This is not a deadlock in classical
> meaning. Of course lock table have no information about which transaction
> updated record before us. We can see this info only in record header and
> we can include it in error message. But what will you do with this transaction
> number ?

Actually, I do this yesterday!
I.e., it returns "update conflicts with concurrent update in transaction
%d".

With the transaction number and the MON$ tables, an admin could know the
connection which is blocking the record.


Adriano