I've put together a simple incremental search app to test the
performance of the TIBIncSearch component. I set up a sample app just
as outlined in the Getting Started Guide, except that I used a 95,000
record table with a fair number of columns and an index on the
LAST_NAME field, upon which I decided to try the incremental search.

For example, let's say I set SearchKeyByKey and SeekNearest to true.
If I start by typing a "z" in for the search, the initial search takes
about nine seconds, during which a dialog pops up that reads "Fetching
Query Results Row #" XXXXX, while XXXXX increments to about 95,000.
It seems that the IB_Grid is being populated with a huge number of
values, which, though providing excellent performance in subsequent
searches, heavily loads the server and provides rather poor
performance for one-off ad hoc searches. For reference, I am
connecting to the server across a 100 Mbit network, and server
processor loading during the nine seconds that the above dialog is
presented is about 25%.

I haven't managed to locate any settings that improve performance by
reducing the size of the result set initially returned by the server.
Is there anything I'm missing in terms of how one should use
IBIncSearch optimally against a large table? I guess there's always
the option of writing custom query code and manually loading my grids,
but I had read a lot about the efficiency of incremental searches in
IBO and had hoped I might manage to avoid that.

Thanks in advance for any suggestions you might provide.

Cheers,
Peter