Subject | Re: [IBO] Transactions |
---|---|
Author | Helen Borrie |
Post date | 2003-07-18T03:04:12Z |
At 12:41 PM 18/07/2003 +1000, you wrote:
transactions, so the datasets are creating their own default
transactions. There's not enough hard info here to draw any conclusions
about anything.
Show us the DFM code for the connection, transaction and dataset objects.
Also, don't use TIB_Query for update SQL. It's too wasteful. Use
TIB_Cursor or TIB_DSQL.
Helen
>Good morning allIt sounds to me as if you have not connected the datasets to their
>
>Supposing I had two transactions and I did something like this:
>
>txnRead.starttransaction;
>qryRead.open; //This sets txnRead.intransaction to false!
>
>txnUpdate.starttransaction;
>qryUpdate.execsql;
>txnUpdate.commit;
>
>qryRead.close;
>if txnRead.intransaction then
> txnRead.commit; //This never executes!
>txnRead.starttransaction;
>qryRead.open;
>
>//both queries are have autocommit = false, and isolation of tiConcurrency.
>//the read query is a TIBOQuery (with datasource attached)
>//the update query is a TIB_Query.
>
>The problem I am having is that as soon as I open the qryRead the first
>time, the
>txnRead suddenly is no longer in a transaction.
>
>This means that after my update and reopening the query, the change is not
>reflected
>in the second opening of qryRead.
>
>However, if I change txnRead isolation to tiCommited, it works (change is
>reflected) from the second opening onward, but the first time I open qryRead
>it still sets txnRead.intransaction to false. I thought tiConcurrency
>isolation was a snapshot?
>
>I can't understand what I have wrong that makes it do this.
transactions, so the datasets are creating their own default
transactions. There's not enough hard info here to draw any conclusions
about anything.
Show us the DFM code for the connection, transaction and dataset objects.
Also, don't use TIB_Query for update SQL. It's too wasteful. Use
TIB_Cursor or TIB_DSQL.
Helen