> thread will be solved. The lock table info will be extracted via SQL
> from a (virtual) MON$LOCKS table (so each engine is responsible for
> exposing this). This is a feature which will be very useful for us in
> finding problems on server.

Exposing lock table info via virtual relation can be not a bad idea but
i doubt it is easy to do. And this info can't help you to resolve problem
you wrote below

> When I have a deadlock (the most encountered
> problem), personally, I want to know who is implied in the deadlock and
> the fb_lock_print is already very cluttered for this simple task.

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 ? And of course it is impossible to include such information into
monitoring table.

> Anyway, the fb_lock_print doesn't work anymore on Win2003 via 'Remote
> Desktop Connection'.

You wrong here. It will work when i'll fix it :)

Regards,
Vlad