Helen;

I understand that getting the keys is more efficient than pulling the
entire row across the network but then I guess that I don't
understand how caInvalidateCursor is different from caFetchAll. I
was also of the impression that if I set AttemptMaxRows to 500 that
IBO would fetch 500 rows and stop but that doesn't seem to be the
case.

Besides simple understanding what I am looking for is a means to
limit the total number of rows returned from these large result sets
the way you could by setting the MAX ROWS parameter in BDE.

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
>
> Stephen,
>
> At 09:36 PM 26/10/2005 +0000, you wrote:
> >I am in the middle of trying to migrate a large application from
BDE
> >to IBO. For better or worse, this application make extensive use
of
> >DBGrids so I need to use TIB_Transaction.TimeoutProps to keep the
OAT
> >moving. I have been trying various combinations of parameters to
see
> >what happens and I am getting confused. I think that I have
> >TimeoutProps figured out but the behaviour of CommitAction has got
me
> >stumped.
> >
> >Since I am using DBGrids I am using a TIBOQuery as my dataset. The
> >SQL for this query is assembled on the fly by the application
based on
> >parameters supplied by the end user so the result set could
> >conceivably be quite large. I have set TimeoutProps as follows:
> >
> >AllowCheckAOT = 5
> >Attemp = 5
> >AttemptMaxRows = 500
> >AttemptRetry = 1
> >AttemptTicks = 250
> >ForceClosed = 0
> >Isolation = tiReadCommitted;
> >
> >If I set CommitAction to caInvalidateCursor, which is what I think
I
> >want, I see IBO fetch 500 records and close the transaction.
Perfect.
> > But after that, I see IBO continually opening a transaction,
> >performing RefreshKeys, and then closing the transaction. Because
of
> >my settings in TimeoutProps it is doing this every couple of
seconds.
> > This has got to be putting a strain on the server.
> >
> >Why is IBO continually refreshing the keys?
>
> Attempt is fetching the remaining rows from the server. Sure, it's
a
> strain on *network resources* if you have a gazillion very wide
rows
> storming across the wire. Requests don't eat much. RefreshKeys is
the
> leanest way to get rows. The server's buffer returns EOF once the
last key
> has been returned - then Attempt has finished its job. The real
cause of
> "straining the server" isn't in fetching rows that are already
waiting in
> the buffer, but in allowing fat sets in the first place to hit-and-
run users.
>
> >How do I make it stop
> >doing this while still leaving the data visible in the grid?
>
> The grid is only the front end for the buffer. AFAIK (not having
tried
> the timeout features with the TDataset components) the controls
aren't
> updated until a human requests it. So, if the human is away at
lunch, the
> control's view won't change.
>
> However, if you are seeing a change in the grid's view while the
> fetch-to-the-death process is going on, this might be down to some
default
> response to EOF by the TDatasource, to nil out all the controls.
You might
> get past it by putting the Attempt process in a
> DisableControls/EnableControls block. This is just guesswork, as I
don't
> use the TDataset stuff myself...
>
> Helen
>