Subject RE: [IBO] Re: CommitAction and automatic AOT advancement
Author Jason Wharton
If they are only grabbing a single record then I suggest you do not use the
Unidirectional = true setting. It is designed to make it efficient to
handle a large dataset.

Regarding how transaction oat processing goes, with unidirectional set to
true I take this to mean the programmer is taking absolute control of the
processing of the query/cursor and if you are not fetched all the way to the
end of a query/cursor then the transaction cannot be ended. Therefore, the
automated behavior of oat processing gets stuffed up when unidirectional is
true on any of the datasets and one or more of the datasets is not fetched
through eof and closed (though I believe I do go ahead and close the cursor
automatically if eof is fetched)

It's a careful balance between what I do automatically for developers and
what I leave under the developers control. My rule of thumb is if a
developer may not appreciate something being changed without them knowing
about it I simply don't do it even if in most cases it would be fine and
even beneficial.

Jason Wharton

> -----Original Message-----
> From: []On
> Behalf Of Stephen Boyd
> Sent: Monday, November 07, 2005 11:25 AM
> To:
> Subject: [IBO] Re: CommitAction and automatic AOT advancement
> Jason;
> The queries in question never need to buffer any records. They
> lookup a single record from the database. Once the record has been
> read, I don't care about it anymore. To my, admittedly BDE centric,
> way of thinking that is what Unidirectional is meant for. Read the
> record and forget it. I have gotten around the problem by building a
> transaction tracing capability into my app. Every 10 seconds I look
> for active transactions and create a list of all queries that have
> open cursors. Then I track down the query in question and close it
> when I am done with it. A pain in the behind but it works. It has
> also forced me to clean up my code a bit.
> Still it would seem to me that automatic OAT advancement should
> behave in the same way, as regards CommitAction, as explicitly
> closing the transaction. If CommitAction = caClosed then the
> transaction should be closed.