Ah Helen! Thanks for hanging in there :-)

> So, if the dataset is small enough to have in memory, what is the
> problem? Setting NOCASE without a proxy search column will
> result in the
> buffer locate as
>
> Uppercase(SearchedColumn) = Uppercase(search criterion), i.e. all
> Delphi, no WHERE clause involved.

That is what I expected also. I think we are on the same track now :-)

> That's not the same as what you described you did to the
> sample app,

Sorry, that is what I have been attempting to describe all along. Sorry if I
have inadvertently confused things.

> where
> you added a mixed case value to the (expected to be all upper
> case) proxy
> search column in the buffer.

OK. Maybe this is the source of the confusion. I don't know anything about
"proxy search column in the buffer". I assumed this is a column that IBO
builds internally with all of the upper case values.

> Maybe I'm missing something here, in understanding what you
> want to achieve.

What I am trying to achieve is very basic. My users cant be relied on to
enter things with any sort of case consistency in reference tables that are
used in dropdown combo lists. So, one row could be 'corp x' while the next
is 'Corp y'. But when using the a dropdown combo they expect to be able to
type 'corp x' followed by a tab and not get an error.

> In practice, I use an indexed, triggered proxy search column
> for any table
> where an incr search potentially needs to fetch more rows
> from the server,
> otherwise I just leave NOCASE alone. Generally I have other
> reasons to
> include proxy columns in large tables, e.g. I want to use it
> for ordering
> output sets to avoid getting reports in strict ascii order.

Right. I have used this approach on large tables also with good results. It
is what Geoff is suggesting also. I have got about 40 of these trivial
reference tables (10 to 20 records in each) spread over 300 forms, so I am
not in a big hurry to start defining new columns and queries for all of them
(this is a BDE conversion exercise).

> The proxy search column is the only way to avoid the cases
> where failure to
> find a match first time is due to the ascii ordering issue,
> OTHER THAN
> approaching this with filters and using the foCaseSensitive option.

Opps. You just lost me :-) Are you saying I can use FilterOptions property
on the dataset that is being used on the TIB_LookupCombo to improve the
function of the case insensitive search? I have assumed that the
FilterOptions only related to the Filter property when Filtered=True. If
that is the case I don't understand how it can help a LookupCombo in this
situation.

> IBO filtering is very quick and smart, btw, much better than TTable's
> filtering. Delphi-style case-insensitive searching can be
> confidently
> expected to work within the filtered set, because the sought
> row is already
> in the buffer.

The sample program has AutoFetchAll:=True so I assume it has all records in
the buffer.

Maybe I have to roll my sleeves up and dive into the source to see first
hand what is going on.

Thanks for you help and perseverance Helen.

Best regards,

Brian

> Helen
>
>
> All for Open and Open for All
> InterBase Developer Initiative · http://www.interbase2000.org
> _______________________________________________________
>
> -------------------------- eGroups Sponsor
> -------------------------~-~>
> eLerts
> It's Easy. It's Fun. Best of All, it's Free!
> http://click.egroups.com/1/9699/1/_/685810/_/975635808/
> --------------------------------------------------------------
> -------_->
>
>
>