I had written:

> >
> >Triggers don't fire until the COMMIT process begins. The Insert
> >function is a client method that sets up a new row on the client
> >side, ready to accept input parameters into the columns. It's
> >impact on the database is nil until Post is called - but even then,
> >the new row is created only as a row version in the current
> >transaction's cache. At that point it must be committed or rolled
> >back to complete and actually store the row permanently. If Commit
> >is called and the row is valid, the triggers will then fire. If it
> >fails, everything fails (including any work the triggers might have
> >done so far).

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.

If your transaction is under tiCommitted isolation and you have AutoCommit true, then your AfterPost view is of work that is committed. 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.

>At least, that's the way it appears to be when using IBO: I have a table that
>uses BEFORE UPDATE triggers to calculate some dependent field's value
>in a table.
>To make this calculation's result visible for the user, I call Post
>on the dataset
>(and have BufferSynchroFlags set to AfterEdit). However, I can still
>call Transaction.Rollback to cancel the all the changes - so I
>conclude that
>no (implicit, IBO-internal magic :-) commit has taken place in between.

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.

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.

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.

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.

>Did I just misunderstand your statement above then?

No, I don't think you misunderstood it. But you seem to be describing Autocommit behaviour...

regards,
Helen

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