Re: Re[2]: [Firebird-devel] Case-insensitive collations

[Peter J. <pj...@wa...>]

Hi Sandor,

> Please forgive me for my english!

Thanks for contributing to the discussion, there is
no need to apologize for your English.

If you want to invest more times into your postings,
don't use it to improve your english put to add more
SQL. 

What I mean with this semi-cryptic comment:
It is sometimes hard (for me), to learn from
a narrative explanation, what is really expected in
different culture's sorting and searching.

So in an optimal posting, you should include a complete, working
example to demonstrate the difference between expected and actual 
behaviour.

I.e.

-- DDL to create the table
CREATE TABLE FOO.... 
... CHARACTER SET .... COLLATE

-- Inserting test data
INSERT INTO FOO ....

-- Select statements
SELECT ... WHERE ... LIKE ... ORDER 

And then your comments, what went wrong:
- too many columns selected (which)
- too few columns selected (which)
- wrong order (show desired order)

As non ISO-8859-1 characters seldom survive the mailing list, you should 
create zipped testcases and upload them to the file areas of firebird-
architect or firebird-i18n

> Be carefull with collations! The "alexandre =3D Alexandr=E9" is not so
> simple.

Yes, and this is the reason that using full multi-level collations and 
STARTING WITH is more powerfull and versatile than just having one,
very aggressive no-case/no-accent collation.

A correctly working "STARTING WITH 'alexandre'" (which can be emulated by 
"BETWEEN 'alexandre' AND 'alexandreZZZ'), would take differences between
languages into account 

> Well, in hungarian language this is not right! Firebird 1.5 has a
> character set (WIN1250) and a collation (PXW_HUNDC) for hungarian but
> it is a mistake. 

The four multi-level collations which exist in Firebird, implement two 
rather different behaviours. AFAIK nobody was willing and able to 
a) really explain the differences and
b) decide which of these are better, or whether both variants should be 
maintained

From my shallow understanding, one variant encodes the 'common use' and th=
e 
other encodes the 'librarian's use'.

> For example:
> In hun. alphabet there are letters a=E1b or A=C1B, the order is importan=
t
> but the case is doesn't matter. Users don't want to press shift to
> try to find a name!
> Firebird solves this problem the following way: a=3DA, a=3D=E1, a=3D=C1!

I dont't think that this is really the case. Please provide a test case as
explained above.

> This is not good! The order is wrong, becouse "=E1" doesn't follow "a"
> and it doesn't work in indexed search but in UPPER().

Please give a complete example.

> So I ask, what is the reason that there's no really case-insensitive
> national support is Firebird? 

See for examples my points A) ... J) in my second answer to Ivan or
my ramblings on http://www.jodelpeter.de/i18n/fbarch/

Regards,
Peter Jacobi