Izvinjavam se što ovo moram da kažem, ali dali je moguće da niko ne zna ili neće da odgovori?

Jedino sto mi pada na pamet je da pokusas gfix-om da vidis gde su greske.Ako smes obrisi ih ili pak edituj.Pa opet sa gfix-om prekontrolisi dali je sve u redu.

A sto se tice cirilice i latinice ja sam u debeloj magli oko toga ( nazalost :-(( ) ali trudim se da izadjem :-)

Preporucujem ti da koristis UTF8/UTF8 kombinaciju. Radi perfektno, doduse ne znam kakva je podrska za Delphi.

UNICODE koristi 3 bajta za svaki karakter, UTF8 koristi razlicit broj bajtova u zavisnosti od samog karaktera (npr. ASCII 1 bajt, Cirilica 2, Kinesko pismo 3 i sl.)

Dakle, u UTF8 kolonu iste velicine, mozes staviti verovatno vise karaktera - sto je dosta bitno za indekse, group by, order by, itd jer postoje razlicita ogranicenja za maks. broj bajtova kod operacija kao sortiranje, indeksiranje i sl.

UNICODE_FSS ima par bugova (npr. nema kontrole - INSERT dozvoljava string od 30 karaktera u char(10) polje i sl.) Mada, mislim da je u FB 2.1 ovo ispravljeno.

Dakle, ako nemas neko ogranicenje zbog samog Delphi-ja, onda koristi UTF8 i da te glava ne boli.

Sto se tice 'malformed string' greske, obavezno procitaj Release Notes PDF koji dolazi uz Firebird. Potrebno je da uradis upgrade svih tvojih baza ako hoces da koristis 2.1. Ako imas stringove u DESCRIPTION ili nekom drugom metadata polju u bazi koji nisu ASCII - npr. koristis cirilicu u nekoj stored proceduri ili trigeru onda ces mozda morati rucno da ispravis stvar. Kazem 'mozda' jer zavisi od admin. alata koji si koristio i koji ti je bio connection charset u tom trenutku kada si radio CREATE/ALTER tog objekta poslednji put.

Restore za metadata ti prolazi - namerno, jer su to dozvolili (kako bi inace uradio upgrade baze kad ne mozes da je prebacis u novi ODS).

Zar ti IBPump ne kaze koje recorde ne moze da kopira? Nisam ga odavno koristio, ali ako ne moze probaj FBCopy pa ce ti tacno reci kad 'pukne'.

U međuvremenu sam napravio malu test bazu i tabelu sa tri varchar kolone sa različitim kombinacijama charset/collation.

Kolona1: UTF8/UNICODE
Kolona2: UTF8/UTF8
Kolona3: UNICODE_FSS/UNICODE_FSS

Zatim sam unosio iste podatke u sve tri kolone koristeći i ćirilicu i latinicu. Uneo sam nekoliko prezimena koja počinju na ČĆŽŠĐ. Na kraju sam imao isti broj zapisa i u ćirilici i u latinici.

Koristeći standardni upit:

dobijo sam (kao što sam i očekivao) različito sortirane podatke, ali ni u jednoj varijanti podaci NISU bili sortirani onako kako sam želeo.

Prvo, u sva tri slučaja, uvek prvo dobijem zapise sa latinicom pa iza njih one sa ćirilicom. Drugo, ni u jednom slučaju podaci nisu bili pravilno sortirani ni po latiničnom ni po ćiriličnom rasporedu, tj. u najboljem slučaju je bilo blagih odstupanja (recimo Č posle Ć, Dž posle Đ, Z posle Ž, i td.). Treće, ćirilično sortiranje je uvek bilo različito od latiničnog, tj. redosled ćiriličnih zapisa se nije poklapao sa latiničnim. Četvrto, sortiranje koje je najbliže pravilnom sam dobijao samo koristeći UTF8/UNICODE (sortiranje po prvoj koloni).

Informacije radi, sve ovo sam probao koristeći Firebird v2.1.1 i FlameRobin v0.8.6, a baza je napravljena sa UTF8 charsetom.

Moje pitanje na ovo je dali je moguće da sam našao bug u unicode sortiranju ili ja možda u nečemu grešim?

Ne možeš da porediš latinično i ćirilično sortiranje, latinično je abecednim, a ćirilično azbučnim redosledom. Nikako nije uporedivo.

Jedna ispravka i jedno pitanje.

Nisam dobro zapazio, ali sortiranje po ćirilici je ispravno kaada se sortira po prvoj koloni, tj. kada se koristi CHARSET/COLLATE kombinacija UTF8/UNICODE. U ostale dve varijante je potpuno pogrešno.

Dali je uopšte moguće dobiti pravilno sortirane podatke kada u istoj tabeli postoje zapisi i sa ćirilicom i sa latinicom? Dali tako nešto uopšte ima smisla?

Još jedna dopuna.

Napravio sam mali test koristeći SQL Server 2000 (MSDE). Kada collation postavim na Croatian_CS_AS, i latinica i ćirilica budu sortirane kako treba, samo što latinični zapisi idu pre ćiriličnih (što je valjda normalno, jer kako reče dogriz koji me je pretekao u odgovoru, besmisleno je porediti ćirilicu i latinicu)...

E, a sad sam u dilemi šta da radim. Dali da nastavim da koristim FB, ili da se prebacim na MSDE???

_{[Ovu poruku je menjao rambo dana 30.07.2008. u 09:03 GMT+1]}

Nema smisla. Nigde u Unicode tabeli ne postoji podatak koja su latinicna slova ekvivalent kojim cirilicnim, tako da ne moze ni tako da se 'mesano' sortira. Jedino kada bi ti napravio takav COLLATION pa ga dodao u Firebird.



Meni nije jasno zasto ti ne radi. Evo, upravo sam probao sa FlameRobinom. Kolona definisana kao UTF8, connection charset isto UTF8. Insertovao sam sva cirilicna slova, i rekao:

select c1 from uctest order by 1 collate unicode

I sve mi lepo slozi (sad vidim da si i ti to primetio). Moras da shvatis kako radi collation. UTF8 collation jednostavno nema taj redosled karaktera kao nasa azbuka/abeceda. Unicode ima. Takodje ima i WIN1251 i WIN1250 kao i BS_BA, ali to su sve collationi za samo jedno pismo (ili cirilicu ili latinicu).

Sad, zasto zelis da dozvolis oba pisma u istoj tabeli iste baze, i jos sortiranje po tome, to je vec drugo pitanje. Inace, mislim da nije preveliki posao da se doda collation tipa Croatian_CS_AS u Firebird - mozda Fikret Hasovic procita ovo pa ti kaze kako (on je napravio BS_BA).