Hi again Stefano!

>*********************************************************
>In one instance, start to enter a new header, but don't post it.
>
>Do the same in the second instance but, this time, try to post it.
>Observe that you get a Deadlock message.
>This is not a problem - it shows that the lock applied in the Before Insert
>trigger by the first instance is working.
>*********************************************************

Here you should get a deadlock error, since you haven't handled the deadlock.

>*********************************************************
>Making use of Planned Deadlocks :
>When the transaction goes to post the new record, it first runs through its
>Before Insert triggers and comes to the one in position 9. There, it looks
>to see if any log rows exist containing recycled invoice numbers. If so, it
>"grabs" the lowest number and performs a dummy update - SET STATUS=STATUS.
>This causes InterBase to lock the set of available rows. Because each
>user's transaction also has LockWait set to true, this causes the Deadlock
>condition for all other contenders for the lowest number. LockWait tells
>the database engine that, if a lock is encountered, the transaction wants to
>wait until the conflict goes away.
>*********************************************************

Here you shouldn't get any error, since you've told IBO to wait (other
transactions are in a deadlock condition since the conflict hasn't been
resolved, but through LockWait you've explicitly told IBO to wait rather
than to report an error).

Note, though, that I've never used LockWait myself and that my
understanding may be flawed (if so, Helen or Jason will bark at me when
they read this).

HTH,
Set