Hi,

Turkish alphabet is based on Latin alphabet. But it has some different letters like ğ,ç,ş,ı,i,ö,ü. These are all different letters and must be sorted according to their alphabetical position. In
DBISAM, all letters are sorted correctly except ı (i without a dot on top, the uppercase of this letter is I) and i (actual english letter and the the uppercase of this is İ, actual english letter I
and a dot on top). The same problem for us (application developed for Turkish market) is exsist in ElevateDB also.

I created a sample table in Delphi7 on XP with ElevateDB Manager, with Turkish Collation and checked/Unchecked Case-Insensitive and Accent-Insensitive, I could not get a solution. It
mixed up i and ı (i without a dot on top.)

Do I omit something or this a feature?

Thanks.

<< Turkish alphabet is based on Latin alphabet. But it has some different
letters like &#287;,ç,&#351;,&#305;,i,ö,ü. These are all different letters
and must be sorted according to their alphabetical position. In DBISAM, all
letters are sorted correctly except &#305; (i without a dot on top, the
uppercase of this letter is I) and i (actual english letter and the the
uppercase of this is &#304;, actual english letter I and a dot on top). The
same problem for us (application developed for Turkish market) is exsist in
ElevateDB also.

I created a sample table in Delphi7 on XP with ElevateDB Manager, with
Turkish Collation and checked/Unchecked Case-Insensitive and
Accent-Insensitive, I could not get a solution. It mixed up i and &#305; (i
without a dot on top.)

Do I omit something or this a feature? >>

I'll have to check this out again, but there was a reason why it was done
this way in the Windows collations.  However, I believe there's a switch
that can turn it on and off.

--
Tim Young
Elevate Software
www.elevatesoft.com

<< Turkish alphabet is based on Latin alphabet. But it has some different
letters like &#287;,ç,&#351;,&#305;,i,ö,ü. These are all different letters
and must be sorted according to their alphabetical position. In DBISAM, all
letters are sorted correctly except &#305; (i without a dot on top, the
uppercase of this letter is I) and i (actual english letter and the the
uppercase of this is &#304;, actual english letter I and a dot on top). The
same problem for us (application developed for Turkish market) is exsist in
ElevateDB also.

I created a sample table in Delphi7 on XP with ElevateDB Manager, with
Turkish Collation and checked/Unchecked Case-Insensitive and
Accent-Insensitive, I could not get a solution. It mixed up i and &#305; (i
without a dot on top.) >>

Okay, I remembered the situation now.  The issue is that only Vista supports
a CompareString call that will allow us to to specify that the comparison
use linguistic instead of file system rules for comparing strings in a
case-insensitive manner:

http://msdn2.microsoft.com/en-us/library/ms647476.aspx

This doesn't work well for us because, obviously, we have to support OS's
prior to Vista, and if we used the linguistic casing on Vista, then it would
make any databases created on Vista appear corrupted on earliers OS's.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:


<< Turkish alphabet is based on Latin alphabet. But it has some different
letters like &#287;,ç,&#351;,&#305;,i,ö,ü. These are all different letters
and must be sorted according to their alphabetical position. In DBISAM, all
letters are sorted correctly except &#305; (i without a dot on top, the
uppercase of this letter is I) and i (actual english letter and the the
uppercase of this is &#304;, actual english letter I and a dot on top). The
same problem for us (application developed for Turkish market) is exsist in
ElevateDB also.

I created a sample table in Delphi7 on XP with ElevateDB Manager, with
Turkish Collation and checked/Unchecked Case-Insensitive and
Accent-Insensitive, I could not get a solution. It mixed up i and &#305; (i
without a dot on top.) >>

Okay, I remembered the situation now.  The issue is that only Vista supports
a CompareString call that will allow us to to specify that the comparison
use linguistic instead of file system rules for comparing strings in a
case-insensitive manner:

http://msdn2.microsoft.com/en-us/library/ms647476.aspx

This doesn't work well for us because, obviously, we have to support OS's
prior to Vista, and if we used the linguistic casing on Vista, then it would
make any databases created on Vista appear corrupted on earliers OS's.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>

This is very bad for us. Some database systems provide their own collation table for each
language; for example bde.

Does the same situation exsist in unicode collation?

Thanks.

<< This is very bad for us. Some database systems provide their own
collation table for each language; for example bde. >>

Yes, but it is silly for a company of our size to ignore the collation
facilities in Windows and spend months (or years) recreating their work.
Even MS uses the Windows collation facilities in their database products.

<< Does the same situation exsist in unicode collation? >>

Yes, it is particular to the NLS facilities in Windows, not particular to
the type of strings used.

--
Tim Young
Elevate Software
www.elevatesoft.com