At 09:44 AM 6/10/2003 +0100, you wrote:

>Hi Helen
>
> >
> > It's not the transaction isolation that causes the OAT to get stuck. It's
> > having read-write transactions that don't get committed, or that use
> > CommitRetaining. If you have your read-write transactions in AutoCommit
> > mode, you are getting CommitRetaining, not hard Commits.
> >
>I am a little concerned by this and would like it clarified. Does this mean
>that if I just put a TIB_Query on a form with a Select statement, leave the
>IB_Transaction as <default> then open the query and leave the form open my
>OAT will be stuck?
>
>Does it imply that every read-only operation should use a ReadOnly
>transaction

No. The original question was whether read-only transactions cause the OAT
to stick. The answer is they don't. But you can't perform DML in a
read-only transaction.

>and that every updating thing (TIB_Query, TIB_Cursor, TIB_DSQL
>etc) should not use AutoCommit?

I'd modify that to say "should not use AutoCommit ad infinitum". As long
as you use only AutoCommit, CommitRetaining will cause the same transaction
context to get renewed afterwards. No garbage collection will occur on the
stuff you've updated because, until a hard commit or a rollback occurs,
it's still "interesting" to the engine's accounting system.

So build in something that does a hard commit from time to time and opens a
new transaction context.

Helen