Subject RE: [IBO] Re: CommitAction and automatic AOT advancement
Author Jason Wharton
IBO should allow you all the same flexibilities that the BDE allowed. I
would like a sample of this so that if somehow I missed a case where I can
do some resource releases where I currently am not, that would be great. It
also may help you to understand better what is going on under the hood and
you might find out the BDE was making you pay a very costly price for its
apparent flexibility.

Jason Wharton

> -----Original Message-----
> From: []On
> Behalf Of Stephen Boyd
> Sent: Thursday, November 03, 2005 6:34 AM
> To:
> Subject: [IBO] Re: CommitAction and automatic AOT advancement
> The query is already set to ReadOnly and I have fetched the only
> record in the result set which means it should be at EOF. Although I
> have fetched the first and only row, I have not tried to fetch until
> EOF is True. Closing the query made the problem go away.
> I am trying to port my application from BDE to IBO and it would have
> been much simpler if I didn't have to worry about closing the queries
> when I am done with them. That was never really a concern with BDE
> so I was a bit sloppy about it. It's going to take some doing to
> find all instances of this in a 200,000 line application.
> --- In, Svein Erling Tysvær
> <svein.erling.tysvaer@k...> wrote:
> >
> > OK, Stephen, here's a guess (note, I'm guessing, in this area I'm
> far
> > from an expert).
> >
> > A unidirectional query can - as far as I understand - best be
> > implemented as a TIB_Cursor. These do not need to be closed,
> reaching
> > EOF "implies" close.
> >
> > Hence, I guess that CursorIsOpen implies that EOF hasn't been
> reached,
> > something which is a good reason for not committing.
> >
> > I don't use TIBOQuery myself (I think that I don't even have it
> > installed), but with a TIB_Query I'd expect setting AutoFetchAll
> > and/or ReadOnly could have helped you.
> >
> > HTH,
> > Set