Sorry,
i post the complete two paragraph

***************************************************
Mix in a little conflict :

Free up some more invoice numbers by deleting some more headers.

Now, open another instance of the application by running the EXE from the
project folder.
Line up the two instances so that you can observe both the header and log
grids of both.

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.

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

>
> Stefano,
>
> the instructions you quote says that it "causes the Deadlock condition",
> not that it returns you a deadlock error. I would expect a LockWait
> transaction to simply wait until the update conflict resolves and then do
> whatever it attempted to do. Probably it just behaves as intended and
> described. Or did I misunderstand what you are saying?
>

Any help would be appreciate

Thanks in davance

Stafano Campri