At 01:20 AM 21/10/2003 +0200, you wrote:

>Helen, Jason, maybe you can something to advise? would be greatefull (as
>usual ;))
>
>have tried to implement searching on several criteria at the same time with
>IB_IncSearch, but there is a problem, when advancing through IB_IncSearch
>new ordering links are activated, so if previous ib_incsearch pointed to
>record (say with number 5 in a dataset), next ordering link will point to
>the new record (but with the same number in a dataset as previous - 5th).

What you're seeing here is "horizontal dataset refinement" doing its
stuff. I've yet to understand the full magic of this but I'll explain it
as far as I do understand...

First, you have to think of an open dataset as a continuum, having n
records at the client, with your grid or other scrolling control focused on
record "X". Record "X" might be the last one you edited, or the last one
you scrolled to with a navigator button, or the last one found by a search....

On the client, the rows in the buffer (forget cache: it's not part of IBO
vocabulary) are kept "in sight" by IBO holding their keys, in the Keyfields
buffer. That's why your KeyLinks settings are so important - they are used
to decide what is stored in KeyFields.

IBO maintains not one but two buffers for the scrolling dataset. One looks
after the buffered rows and those waiting on the server. The other takes
care of all rows before the buffer. In between is the "window" of rows
actually in the buffer right now.

When searching, IBO considers various possible sets that it could have in
the buffer to satisfy the current search criteria. It can tell from its
Keyfields whether it already has them in the buffer or whether it has to
refresh the buffer in order to have the requested rows available. Every
fresh request for rows gets fresh parameters and, if the ordering or the
list of searched columns change, it actually has to issue a new query.

When you do an incremental search, you are not looking for a single record
- you are looking for all records that match [STARTING WITH :aString],
which is the set of characters that has been typed into the control. With
each extra character you type, it refines the search horizontally (left to
right across the aString value, as it grows). Depending on how fast or
slow your typing is, IBO is busy making up a new parameter to pass to
:aString and is pull back fewer and fewer records each time, as the HDR
gets nearer and nearer to identifying a single record.

The search is always an ordered search, to ensure that the records with the
search field matching the ordering item come out first.

>Moved to IB_ParamEdit - everything is ok
>select "Name" , "Surname" from Table
>where "Name" starting with :Name and "Surname" starting with :Surname:
>
>but I miss 2 great features:
>- there is no autocompletion of a selected nearest record (IB_IncSearch has
>it) - looked into IB_IncSearch.pas but failed to understand, where is
>autocompletion code;

Look at the SeekNearest property of TIB_IncSearch. This *is* the
incremental search control. Incremental search characteristics are
available on TIB_Grid, TIB_LookupCombo and TIB_LookupList as well.

>- select doesn't use cached dataset, it make query every time on key press;

Of course it queries - this isn't Access!! - but not necessarily every
time. If it has all of the requested rows already in the buffer, it simply
repositions. You will see queries happening on the occasions when some or
all of your requested rows are not present in the buffer.

>How I would implement those features (to use cached dataset + get
>autocompletion)?

Cached datasets are not meant for searching. They are designed to isolate
selected rows from the server and "trap" them for off=line editing. They
stay isolated until updates are applied and committed. Cached datasets are
for delayed edits. They are a crock in a client/server system. Forget them.

Helen