At 03:15 PM 23-10-01 +0200, Nando Dessena wrote:

>Lukas,
>
> > But my confusion was about *when triggers get fired* (not their
> > result committed). I still think triggers get executed when data is
> > posted (i.e. when IBO sends an UPDATE statement).
>
>no doubt it works this way. I think you and Helen are just using
>different terminologies.

Actually, no, I was a a bit "out" with the timing of the trigger operations. I checked it out with Ann Harrison and she says that datasets inside the same transaction will know about the results of trigger operations (in new record versions) after the Post completes and *before* the commit action begins.

So - when the trigger fires, and causes the update to the dependent table, the previously committed of the dep. table's record is now locked to all transactions except the one in which the Post occurred..

In Ann's words -
"The only things that wait for commit are metadata operations and
the actual sending of event notification to those waiting on the event.
...
"Uncommitted changes are visible to the transaction that creates them
as soon as the operation that created them completes. If the transaction
has 14 active statements, each statement gets the same view of data -
i.e. they all see the changes."

(AFAICT, that doesn't affect the client-side view that the dependent dataset shows, because server action couldn't change its buffer - but Jason will be the one to tell us what, if anything, happens in the buffers of those dependent sets...)

So - I hope this clears it up. My next task is to turn the scenario that I sent through to Ann, along with her step-by-step description of what's happening on the server, into something that is crystal-clear. Hmm.

cheers,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________