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

Did you change an error number or error message only ? Or you added
new secondary error code ?

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

Only if this transaction still active when admin decide to do something
with it. Highly unreal scenario i think.

Regards,
Vlad