> Hm, I played with the char sets, as you recommended. Database was
> created with "NONE" (whatever that means) and connection char set
> was empty. I tried to convert both to WIN1250, but it didn't change
> anything.

NONE is essentially ASCII byte-order. Most of the other character
sets have specialised collations which take into account combinations
of characters and so on. There are articles available via the various
IB/FB websites where you can get better explanations.

> What did you mean with "sort order in Windows configuration?".

What I have discovered in the past is that special characters '-' and
'/' etc have impacts on the AnsiCompareStr and AnsiCompareText methods
used to sort strings.

Take for example the following list...

Abc
aBc
a-bc
a/bc
a\bc

Sorted in a TListBox (locale = Australia) they become...

a/bc
a\bc
aBc
Abc
a-bc

Now select the same list from a table (character set NONE) in the
database using case insenstive sort and you get...

a-bc
a/bc
aBc
Abc
a\bc


I will leave the case-sensitive variation of this for your
experiments. The point being that Windows does NOT sort/compare in
standard ASCII order, but according the defined locale. This often
makes the results unpredictable when special characters are included
in the strings as shown above.

What you need to do (if you are attempting to sort strings containing
special characters) is use a database character set that matches your
windows character set as closely as possible. I believe the WIN12nn
character sets are considered to be close matches depending on your
windows locale.

Alternatively you can implement your own compare methods using the
TIB_Connection OnCustomCompareStr and OnCustomCompareText event
handlers. For example you should setup ASCII comparisons for a
database using character set NONE (which is easy, just use CompareStr
and CompareText methods).

hth

--
Geoff Worboys - TeamIBO
Telesis Computing