Thank you Peter!
I changed the COLLATE to "PXW_TURK"; everything improved!
my English information is inadequate. I will to ask for help from my
friend to reply to you as detailed. In addition, however i will try
and learn what you said.

see you Peter monday.
Esref Atak

--- In firebird-support@yahoogroups.com, "peter_jacobi.rm"
<peter_jacobi@g...> wrote:

> Hi Esref!
>
> Esref Atak wrote:
> > > For a quick test I suggest, just switching to the FB1.5.1 release
> > > candidate at:
> > > http://www.firebirdsql.org/download/prerelease/1.5.1/
> > >
> > > Does everything magically starts working?
> >
> > reply is "No".
>
> Does the "Transliteration Error" still occur or is the sort order
> still wrong?
>
> > I tried the ISQL tool:
> [...]
> > When i use "ORDER BY AD" the records are ordered with fault. It
> > orders the Turkish characters at the end of the ordered records.
>
> That's the normal behaviour when you don't set COLLATE PXW_TURK.
> I've prepared a small sample script which you can use with
> ISQL. It should give you correct sort order and uppercasing
> when using column c2, which has PXW_TURK. In contrast you can
> see the "normal" (not usefull for Turkish) sort order, when
> using column c1.
>
> Thanks to note for this test:
>
> A) The snipped is in cp1254, if it doesn't look Turkish
> anymore (no dotless i), when received and saved to a text file,
> you have to use the zipped, uuencoded version below.
>
> B) Set your console to cp1254 using "chcp 1254" and verify
> by TYPEinge the SQL-script, that the Turkish characters are
> displayed correctly.
>
> C) Then use "isql -e -i pxw1254test.zip" to run the test.
>
> D) The difference between FB1.5 and FB1.5.1 is, that you
> don't need to "set names WIN1254" for FB1.5.1 - please
> verify also this.
>
> For some background about all this you may want to check:
>

http://www.jodelpeter.de/i18n/fbarch/selecting_charset_and_collation_in_fir=
=

> ebird.html
>
> > That is; there is no problem in JDBC or ColdFusion?
>
> IMHO ColdFusion simply cannot make this not work, except when
> doing something incredibly stupid.
>
> The exact behaviour of JDBC should be discussed on JDBC list.
>
> Regards,
> Peter Jacobi
>
> ---- snip ----- (this snipped uses code page 1254 charset)
>
> set names WIN1254;
> connect 'cstest.alias' user 'sysdba' password 'masterkey';
>
> drop table PXWTURKTEST;
>
> create table PXWTURKTEST (
> c1 varchar(8) character set WIN1254,
> c2 varchar(8) character set WIN1254 collate PXW_TURK
> );
>
> commit;
>
> insert into PXWTURKTEST (c1) values ('ç');
> insert into PXWTURKTEST (c1) values ('Ç');
> insert into PXWTURKTEST (c1) values ('ð');
> insert into PXWTURKTEST (c1) values ('Ð');
> insert into PXWTURKTEST (c1) values ('ý');
> insert into PXWTURKTEST (c1) values ('I');
> insert into PXWTURKTEST (c1) values ('i');
> insert into PXWTURKTEST (c1) values ('Ý');
> insert into PXWTURKTEST (c1) values ('ö');
> insert into PXWTURKTEST (c1) values ('Ö');
> insert into PXWTURKTEST (c1) values ('þ');
> insert into PXWTURKTEST (c1) values ('Þ');
> insert into PXWTURKTEST (c1) values ('ü');
> insert into PXWTURKTEST (c1) values ('Ü');
>
> commit;
>
> update PXWTURKTEST set c2=c1;
>
> commit;
>
> select c1, UPPER(c1), c2, UPPER(c2) from PXWTURKTEST order by c1;
> select c1, UPPER(c1), c2, UPPER(c2) from PXWTURKTEST order by c2;
>
> ---- snip -----
>
> And the same, zipped and UUencoded:
>
> begin 0777 PXW1254.ZIP
> M4$L#!!0 @ ( !IVZC#^)^:9, $ #,$ / <'AW,3(U-'1E<W0N<W%L
> MI9,Q2\1 $(7[0/[#=)M $!(4A,/RBD.0<.8X.]E,5@QNLF%GH^07VEI9J:VM
> ME96*N_$XB%=XB]MDPWSSWDN8(6&@Y8T@6"_.TNSH<!8&J-I6H &&9 29 RYK
> M3@QZ$AH8#525G$''B>Z4KH UW&+Z1@S,]H9!I54'AI=20'ZQ+E;+TV)^7HPE
> MU((;L5N$* P ,(5;KO&:Z^@X!O?D:(6!;,1-N&3DLC\Y0"6EL[(FE\XE#.*?
> M!*II:C->Z]9^CX&Z-6J:!=/8&LC>_I.(O;)X!I.S;^<]<Y;[L6\>[(,'^^G!
> M+CS8VH-]]F#?/=A'#_;+@WWQ8#\\V">V,X)]5VV&=-OCAABS$TQ_LR2DVTE,
> M$UCE^7SIQ!.+;E^S&*ZT:B9J=C_M8I0#C'K_E,C&'&'P#5!+ 0(6"Q0 @ (
> M !IVZC#^)^:9, $ #,$ / $ ( "V@0 !P>'<Q,C4T=&5S
> ;="YS<6Q02P4& $ 0 ] 70$
> end