Thanks for your answer. Iam aware about the large result- problem but I
always tend to disagree when I hear: not possible....

My target clients are all 100MB so I do optimize for that. When doing my
first test with the large database I was amazed how quick interbase/ibo gave
a instant result back when only quering for specific streets. So Interbase
has no speed problem to return anything specific from 500.000 rows. That
leads me to believe there should by a possibilty to do incrematal search:

When doing an incremental search the first thing that's important wether the
keyed combination gives an result anyway. I tried to find a solution by
searching first for a result with only one row returning. I found this by
doing a query.first.

I created an simple example and ib_query/editbox/ib_grid/ib_datasource with
the following query:

Select * from zipcode where street starts with :PR1

when pressing an key inside the editbox the following is happening:

procedure TMDIChild.Edit1KeyPress(Sender: TObject; var Key: Char);
begin

with IB_Query2 do begin
if IB_Query2.Prepared then
IB_Query2.Unprepare;
IB_Query2.ParamByName('PR1').Asstring:=edit1.text+Key;
IB_Query2.Prepare;
IB_Query2.First;
end;
end;

I connected the ib_grid to the datasource. It's refreshing automaticly and
showing/filling only the rows visible inside the grid.

The results are great. The only data transfered are the rows inside the
grid. No more rowfetch at all. It doesn't matter wich letters I presse I get
instant result from the 500.000 streets (and yes there are a lot of streets
before the B).

Am I totally wrong with this approach? Would this lead to unaccaptable
performance at the server for other query's. I think there really small...
only repeated a lot of times.


Bram van der Voet