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