At 01:11 PM 10-12-02 -0800, you wrote:

>Ok, but I'm not sure this applies in my situation. If you look at my
>original post, I'm NOT doing an Insert(), Set Fields, Post(). I'm doing it
>manually, generating the SQL myself, setting the SQL parameter of TIB_DSQL,
>and doing an Execute(), then a Commit() on the transaction. I don't think
>POST applies in this situation, or does it?

Yes. The effects of executed operation do not become permanent in the
database until the transaction is committed.

>Isn't the data sent to the server when I do the Execute()? I think you're
>just misunderstanding what I'm doing.

You need to understand what you are doing. When you do the Execute, the
"data" that are sent to the server are just a statement, no different to
what happens when the work from calls by the dataset to Insert, Edit or
Delete occur. Your statement is posted, awaiting a call from the client to
commit or roll back.

>TIB_DSQL doesn't have the BeforeInsert and AfterInsert triggers.

BeforeInsert and AfterInsert are not triggers, they are client events of a
dataset. TIB_DSQL does not have these events because it isn't a dataset.

Triggers happen only on the server and they fire whenever the relevant DML
statements are posted. The server has no knowledge of what is happening on
the client...to the server, it's all the same whether the statement came
from a dataset call, a raw statement (i.e. a TIB_DSQL) or from a client
tool like ISQL.

Don't confuse posting with committing.

--- Statements are posted.
--- Transactions are committed.

So, in a single transaction, you can post many statements. Eventually you
commit the transaction and those posted statements all become permanent in
the database together. If you rollback the transaction instead, all of
those posted statements are undone together.

Helen