> Since I use the search mode and don't use locate, IncSearchs I think
> that having three cursors is worse than just having one.

Locate is the instance where FetchWholeRows is probably less
efficient, because (depending on what you are locating) it may require
searching through the records.

Search mode is great because it filters the original set of records
meaning there are less records loaded back to the client anyway.

I am also wondering if the description you quoted may be somewhat
misleading - or at least not the whole story. Editable queries
usually have multiple internal statements anyway, FetchWholeRows
simply introduces one more.

If you have two TIB_Query components then you will have more actual
statements created (and needing prepare etc) - and depending on how
you configure the editable query you may end up being less efficient
by buffering more records than you need (I would suggest a
master/detail config so the second query only ever loads one record -
either that or set up a manual synchronisation process).

Keep in mind that every time the grid query scrolls the second query
is going to read the corresponding record from the server (unless you
perform a manual sync so it only updates when about to edit). This
will add to the network load (in a small way, but I suspect comparable
to using FetchWholeRows=true).


I guess my point is that I *suspect* using FetchWholeRows will be as
efficient as your two TIB_Query approach - and it is a whole lot
simpler. The only way to be certain is to test it out (you can use
the IB_Status form to report on number of statements etc). And the
beauty of FetchWholeRows is that you can easily turn it off/on
according to a particular situation. For example on a wide-band
network having it on may be more effective/efficient, while turning it
on for a narrow-band network on may be better.

Its your choice, I'm just offering my opinion.

--
Geoff Worboys
Telesis Computing