Hello again,

At 20:46 +1000 22.10.2001, you, Helen Borrie wrote:

>I had written:
>
>> >
> > >Triggers don't fire until the COMMIT process begins.
>[..removed details]
>
>At 11:36 AM 22-10-01 +0200, Lukas Zeller wrote:
>
>>Just for curiosity: Are you sure this is 100% correct?
>>
> >I thought that triggers fire when a change is POSTed. Of course, the changes
> >caused by the trigger happen in the current transaction's context,
> >and will only
> >get permanent with COMMIT.
>
>If Autocommit is true, then changes will be permanent when you post.
>But Autocommit does CommitRetaining, so, if Rollback gets called
>instead of another CommitRetaining or a Commit, only the work posted
>since the Savepoint of the previous CommitRetaining will get rolled
>back.

Autocommit is false.

>If your transaction is under tiCommitted isolation

it is...

>and you have AutoCommit true, then your AfterPost view is of work
>that is committed.

Yes, I understand that. But as said, Autocommit is false.

>After an edit and before a commit, the dependent datasets won't see
>the changes, even inside the same transaction, because their view is
>only of committed work.

Yes, agreed.
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). I agree that the
results of the trigger's execution will not be visible in other
transactions nor other datasets in the same transaction but it WILL
be visible in the dataset that has posted the changes (if it has
BufferSynchroFlags=[afterEdit]). That means that (BEFORE UPDATE-type)
triggers are fired at the moment the UPDATE statement gets executed.
I used IBO Trace Monitor to see what happens, and I see that on post,
IBO issues an UPDATE statement, followed by some FETCH operations to
get an updated view of the fields, which includes the work of my
BEFORE UPDATE triggers. Note that there is NO commit nor
rollback of any sort happening.

>Even after the CommitRetaining has occurred (meaning the triggers
>affecting the dependent tables have committed work on the dependent
>tables) I think the dependent datasets may still not see the effects
>of the triggers unless they are refreshed...I haven't tried it and I
>guess I don't expect that they would.

I would agree, but this is not because the triggers haven't executed yet, but
the results of the execution is not yet committed.

>If you can see the effects of CommitRetaining in other datasets
>without refreshing them, we ought to wait for Jason to explain how
>he does that.

I can't :-)

>If a Before Insert trigger fires a generator, its value *will* be
>available inside the uncommitted transaction because generators are
>not subject to transaction control - that number is "used-up" the
>moment it is generated. If the uncommitted work is rolled back,
>that number will be gone, not eligible to be generated again.

Yes. And it fires when the record is posted, not when it is committed. The same
applies to BEFORE UPDATE triggers. That's my original point.

>But a COMPUTED BY column is output from the database, never stored
>there, even in the uncommitted versions, so it won't be available
>until the arguments of its calculation algorithm are present in the
>committed row.

I didn't try this, but I assume that COMPUTED BY fields will be
calculated at the time
when the client fetches a row, so with BufferSynchroFlags=[afterEdit] a client
dataset would see the COMPUTED BY results based on most recently posted data.

Still somewhat confused...

--
Lukas Zeller (luz@...)
-
Synthesis AG, Sustainable Software Concepts
info@..., http://www.synthesis.ch