Thnx for your help/suggestions. I changed to this:

procedure TMDIChild.Edit1KeyPress(Sender: TObject; var Key: Char);
begin
IB_Query2.ParamByName('PR1').Asstring:=edit1.text+Key;
IB_Query2.First;
end;

This also seems to work. I didn't understand the active/close part you
added? It doesn't seems to effect the speed so I could leave it out?
Should a stored procedure in this case works even faster. I should try
anyway I think...

It's true that pressing the first key in this case is useless... But
perfomance wise it really doesn't matter. I think you have to keep an
standerd in applications and it would be difficult for people to understand
why one input start directly and the other on the second or third key
pressed.

I changed my example to the zipcode, this seems to works even faster. It
starts with number (our format is 1234 AA). I get almost instant response so
I'am really happy with my incremental search on 500.000 records so far. But
I still need to iron out some things like not start searching if keys are
pressed very quickly. And the first search is still a bit slow.


-----Oorspronkelijk bericht-----
Van: Svein Erling Tysvær
[mailto:svein.erling.tysvaer@...]
Verzonden: donderdag 18 januari 2001 08:37
Aan: IBObjects@egroups.com
Onderwerp: RE: [IBO] increment search


Hi Bram,

you do a bit unneccessary and confusing work in your example. There's no
need to Unprepare your IB_Query2, just make sure it is closed. Repreparing
is only required when you change the SQL statement, not when you change the
value of a parameter. And ParamByName automatically prepares a statement if
neccessary (which has to be done to make the parameters available), so your
call to IB_Query2.Prepare is redundant (you may include "if not
IB_Query2.Prepared then IB_Query.Prepare" for readability before you set
the parameter). I suggest you change your code to

procedure TMDIChild.Edit1KeyPress(Sender: TObject; var Key: Char);
begin
if IB_Query2.Active then
IB_Query2.Close;
{ if not IB_Query2.Prepared then
IB_Query.Prepare;} //This "if" is optional
IB_Query2.ParamByName('PR1').Asstring:=edit1.text+Key;
IB_Query2.First;
end;

When it comes to incremental searching, I think it is possible to set a
parameter which specifies how many characters must be typed before the
incremental search begins. It would surprise me if starting the incremental
search after the first character would be a good idea when the table
contains 500 000 street names. The odds for being on the right record
immediately is rather low, and do many streets in the Netherlands have a
name of only one character? (if so, I think it would only be to hit enter
after the character).

Good luck,
Set

At 16:48 17.01.2001 +0100, you wrote:

>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
>
>
>
>
>