> Your comments about case-sensitivity, character sets and collation
> orders are correct, but the sequence I typed still produces wrong
> results. There are no nulls or entries with special characters in my
> table.

> See my previous description of the behaviour:

>> (a) type "I" => item "IG/L Chain" is selected [ok]
>> (b) type "g" => item "IG/L Chain" remains selected, which is strange
>> because inc search should be case sensitive and there is an
>> item "IgA" below.

It was these examples which led to the information that I posted. '/'
sorts differently under Windows (at least in locale Australia) than it
does in ASCII (character set NONE). What locale is your windows setup
to use?? (Some locales do interesting things with combinations of
letters as well.)

Just because the particular characters dont appear at the positions
you are searching for does not mean they are not causing problems.

However that said, I am not certain that that is your problem, I am
just saying that you cannot exclude it until your go through all your
entries and remove the special characters OR (as I suggested earlier)
attach code the to OnCustomCompareText and OnCustomCompareStr handlers
for TIB_Connection. Implement the comparisons using the VCL
CompareStr and CompareText functions (not the Ansi* variations) and
see if the problem resolves.

If that does not resolve the problem then I think you will need to
setup a demo - including a database and email to myself or Jason.
Please gbak the database first and zip it all (to keep the download
size small.

--
Geoff Worboys - TeamIBO
Telesis Computing