Subject | Re: [IBO] [IB_SQL] How to use IB_SQL like SqlMonitor |
---|---|
Author | Paul Vinkenoog |
Post date | 2003-06-13T03:10:29Z |
Hi Stefano,
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.
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.
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.
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.
Greetings,
Paul Vinkenoog
> > > i would like to see what's DML is executed when at run-timeI can't test this thing because I don't have a working Delphi here at
> > > the insert button of a TIB_UpdateBar is clickked
> >
> > Probably nothing; this just puts the dataset (in the app) in
> > dssInsert state, it doesn't post anything. It might do a Prepare
> > under some circumstances.
>
> You are right : no DML is executed
>
> Could you comment this ?
> *******************************************************************
> (extrated from : www.ibobjects.com/docs/ti_AuditableSeries.ZIP)
> 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.
> ********************************************************************
>
> how can a trigger be invoked if cliccking insert row on the
> TIB_UpdateBar does not effect on the database ???
>
> what's the solution to make the example working ???
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.
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.
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.
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.
Greetings,
Paul Vinkenoog