> I can't test this thing because I don't have a working Delphi here at
> the moment, but I get the impression the text isn't correct at this
> point. Because AFAIK, "inserting" something in an IBO field without
> posting means that nothing is sent to the InterBase/Firebird client
> API. The "inserted" record only exists within IBO, i.e. within your
> program.

you are right, nothing is sent : i tested it with theTIB_Monitor

> And since IB/FB didn't receive this insert (yet), it can't bloody well
> execute any "before insert" or "after insert" trigger on it. This in
> turn means that, as long as your "inserted" record sits quietly within
> IBO, no INV_NUMBER is generated or gotten from INV_LOG, and no INV_LOG
> record is locked.

that's for sure !

> Maybe the author meant: let the first instance of the app insert a
> record, post it, but don't let it COMMIT the transaction yet. Then let
> the second instance try to post a new record.

i agree but how ?
everything is done clicking the post button on the TIB_UpdateBar, there is
no code
how can i prevent a commit cliccking the post button ?

>
> Anyway, like I said: I can't test it.
>
> Do I understand correctly that you could not reproduce the deadlock if
> you just inserted (IBO-inserted, that is) without posting (= without
> really inserting it into the database system) ?
> If so, that's exactly what I would expect.

you understand correctly and deadlock is not raised

to validate our argument i locked the record via IB_SQL
then inserting and posting via the test application at last i got
the wanted deadlock

Stefano Campri