Subject Re: CommitAction and automatic AOT advancement
Author Stephen Boyd
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.


--- In IBObjects@yahoogroups.com, "Jason Wharton" <jwharton@i...>
wrote:
>
> I believe setting unidirectional to True is where you are getting
problems.
>
> Here's a rule of thumb: If your query is ever going to need to
buffer more
> than one record at a time, DO NOT USE UNIDIRECTIONAL.
>
> If unidirectional is true it means you are totally in control of
the query
> and the automatic features of IBO handling the OAT advancement are
> potentially intrusive and therefore benign.
>
> Jason Wharton
>
>
> > -----Original Message-----
> > From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
On
> > Behalf Of Stephen Boyd
> > Sent: Wednesday, November 02, 2005 8:38 AM
> > To: IBObjects@yahoogroups.com
> > Subject: [IBO] CommitAction and automatic AOT advancement
> >
> >
> > I am trying very hard to understand the relationship between
> > CommitAction and automatic OAT advancement. I thought I had it
> > figured out but I have come across a situation where it doesn't
work
> > the way I thought it did. I am using TIBOQuery with
TIB_Connection
> > and TIB_Transactions components.
> >
> > The strategy that I have adopted is to set CommitAction to
caClose for
> > all queries that are used to look up values and to set
CommitAction to
> > caFetchAll for all queries that drive DBGrids. Lookup queries
have
> > Unidirectional set to True. I have set the TimeoutProps as
follows:
> >
> > AllowCheckOAT = 10
> > Attempt = 5
> > AttemptMaxRow = 1000
> > AttemptRetry = 1
> > AttemptTicks = 250
> >
> > In most situations this appears to work the way I expect. That is
> > caClose queries are close, caFetchAll queries are fetched to EOF
and
> > the transaction is commited. But I have 1 query where this
doesn't
> > seem to work so I started digging around with the debugger and
> > discovered that queries with Unidirectional = True and do not get
> > forced closed. In TIB_Transaction.SysTimeoutAttempt we have the
> > following code:
> >
> > CanAttemptCommit := true;
> > for ii := 0 to DatasetCount - 1 do
> > with Datasets[ ii ] do
> > begin
> > if CursorIsOpen then
> > ---------------->
> > if Unidirectional or Fetching {or ( BufferRowCount >
1000 )}
> > then
> > begin
> > CanAttemptCommit := false;
> > Break;
> > end
> > <-----------------
> > CanAttemptCommit := true;
> > for ii := 0 to DatasetCount - 1 do
> > with Datasets[ ii ] do
> > begin
> > if CursorIsOpen then
> > if Unidirectional or Fetching {or ( BufferRowCount >
1000 )}
> > then
> > begin
> > CanAttemptCommit := false;
> > Break;
> > end
> >
> > Why do Unidirectional queries not get forced closed? If
CommitAction =
> > caClose then isn't that an indication that I don't care about the
> > content of this query? What do I have to do the get the OAT to
> > advance in this situation?
>