Helen, I am currently setting it to tiReadCommitted because
somewhere, in this forum, I read that I need to set
read committed and do not use autocommit (server or local).
I forget why now, but it was what I needed as a basic
setting(s) I was under the impression that to commit it
would close the datasets relating to the database and
would therefore _lose_ the record I was letting the user
view.
This is for a basic invoice/lineitem type of system,
with twists relevant to our situation. I would make the
changes in the background to the line items and the base
totals, etc with a tib_cursor or a tib_dsql, (whatever it
takes) but needed the values to update immediately on posting
the lineitem changes. I am using all of the DML settings as
true for each dataset involved (TIB_Queries and a few
tib_cursors).

Steve Fields

Helen Borrie wrote:

>
> What transaction isolation are your datasets running in? If it's not
> tiCommitted, then it won't see the outcome of the DML until next time its
> transaction is committed via a hard commit, even if you refresh it in
> response to a DMLCaching signal.
>
> Don't use CommitRetaining for your on-the-fly SQL statement's transaction,
> since the purpose of CommitRetaining is to retain the same transaction
> context. This will affect the rowset which the update statement's
> transaction can see as "eligible".
>
> Helen
>
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/