> > So what's faster, I have tried to read on the benefit/drawback of using
> > Where Query vs Filter but nothing that puts the clock straight.
>
> It´s depending on the size/amount of your data.
> Filtering is entirely done by the client, what means that all data has
> to be fetched from the server into the client buffers and then comparing
> is done. If the dataset is large, it needs time to transfer all data to

the

> client, and in second step all comparing has to be done. Also you need lot
> of memory resources to bring all data to it´s buffers.
>
> With the Where query, finding the result set is entirely done by the

server,

> which in most cases is much faster. Also, only a small result set has to

be

> transferred over the network to the client buffers.
>
> I would use filters only on very small dataset´s which stay open for long

time.

Actually with IBO filters are resolved and sent to the server in the form of
alterations to the WHERE clause. If you use the OnFilterRecord event then
you are using client-side filtering, but only then. Incremental searching is
also a client-side operation that should be used with care. Making it
somewhat server-side is possible but not well documented.

Using the LIKE operator with a parameter makes it perform without the
benefit of any indexes. It is similar to CONTAINING in that respect but it
is case sensitive where CONTAINING is not case sensitive.

I recommend against using CONTAINING or LIKE with the search edit control.
Instead, just put it into search mode and allow the user to enter their
criteria. CONTAINING 'stuff' is valid search criteria. You can also use a
string with the LIKE wildcard operators in it and IBO will automatically use
the LIKE operator for you. You can also allow the user to type in STARTING
WITH 'stuff' or set the NOTRAILING attribute and this will happen
automatically. If you want it to do a direct comparison use the ='stuff'
criteria.

HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com