Par cinjenica:
MySQL Server 4.0.x
nema podrsku za karakter setove.
MySQL Server 4.0, 4.1, 5.0, 5.1 latin1
nije ISO/IEC 8859-1 vec "malo" promenjeni latin1 (ista prica i za latin2)
Na zalost, najsigurniji upgrade, bez gubitka karaktera sa 4.0 je "preko" 4.1, dakle, uradite upgrade na 4.1 pa onda na 5.0. Trebalo bi da funkcionise ista procedura i direktno na 5.0 ali to toliko dugo nije testirano da se i dalje savetuje 4.0 -> 4.1 -> 5.0 ako se koriste karakteri koji nisu "ascii7"
Pogledaj
ovaj link.
Kratko uputstvo za upgrade sa 4.0 na 5.0
1. pre bilo cega - napravite bekap (najlakse je da zaustavite MySQL Server i iskopirate ceo datadir direktorijum na sigurno)
recimo da imamo tabelu:
Code:
create table `t1` (
`latin1f` CHAR(50),
`latin2f` CHAR(50),
`utf8f` CHAR(150)
);
u `latin1f` smo cuvali "latin1 enkodovane stringove", u `latin2d` smo cuvali "latin2 ekodovane stringove" i u `utf8f` smo cuvali "utf8 enkodovane stringove"
?kako je to moguce kada MySQL 4.0 ne podrzava karakter setove?
Lako, upisuje ih binarno i ne interpretira ih, "podska za karakter setove" znaci da je RDBMS svestan u kom formatu je podatak sacuvan, u kom formatu ga dobija od klijenta i u kom formatu ga klijent trazi nazad te u letu radi potrebnu konverziju. MySQL 4.0 nema tu podrsku te sve to prima, salje i cuva "binarno".
Citat:
Kada se u takvu bazu ubacuju nasi karakteri u latin2 encoding-u (iz php aplikacije ili phpmyadmin-a recimo, ti karakteri se cuvaju kao hijeroglifice :) u samoj bazi).
Medjutim, svi klijenti te karaktere citaju kao latin2 (ako se tako definise), tako i kad exportujem bazu, bilo preko phpmyadmin-a ili mysqldump-a.
Dakle ovde imamo klasican primer navedenog, klijent salje i ocekuje karaktere kao "latin2", RDBMS toga apsolutno nije svestan i cuva te karaktere binarno, dakle ovo je primer " `latin2f` CHAR(50), "
Dump sa 4.0 -> Restore na 4.1 ovde nece mnogo pomoci, nego prvo, promenimo onu nasu tabelu tako da one karakter setove koji nisu latin prebacimo u ono sto oni zapravo jesu:
Code:
--ovo je ono sto bi OP morao da odradi na verovatno SVIM char poljima u bazi
ALTER TABLE `t1` MODIFY `latin2f` BINARY(50);
--ovo na "par" onih gde je mozda koristio utf8
ALTER TABLE `t1` MODIFY `utf8f` BINARY(150);
Zaustavimo server i uradimo upgrade
sa 4.0 -> 4.1
Startujemo MySQL 4.1 na postojecim podacima i sada ponovo promenimo ona dva polja u "valjane" tipove sa definisanim karakter setom:
Code:
--ovo je ono sto bi OP morao da odradi na verovatno SVIM char poljima u bazi
ALTER TABLE `t1` MODIFY `latin2f` CHAR(50) CHARACTER SET latin2,
--ovo na "par" onih gde je mozda koristio utf8
ALTER TABLE `t1` MODIFY `utf8f` CHAR(150) CHARACTER SET utf8;
onda opet to lepo sve ugasimo, uradimo
upgrade na 5.0
startujemo mysql_upgrade script po zavrsetku upgrade-a da isproverava i update-uje tabele i spremni smo za rad
Obratite paznju da se mnogo toga promenilo od 4.0 do 5.0, neke od tih promena nisu kompatibilne
na
linku za upgrade 4.1 -> 5.0 mozete naci listu nekompatibilnih izmena izmedju 4.1 i 5.0
a na
linku za upgrade sa 4.0 -> 4.1 mozete naci listu nekompatibilnih izmena od 4.0 do 4.1
EDIT: code tag ne radi "word wrap" ubi se da nadjem sto mi siri div :)