Převod dat z MySQL 4.0 do MySQL 4.1

MyEgo.cz

home foto blogy mywindows.cz kontakt

Převod dat z MySQL 4.0 do MySQL 4.1

PHP 06.12.05
MySQL 4.0 do 4.1

Upravoval jsem dnes prezentaci Města Český Brod (do redakčního systému byla doplněna například automatická expirace článků či zobrazení počtu článků v dané sekci, což jsou velice podstatné funkce pro funkci Úřední deska) a při té příležitosti jsem chtěl i přesunout data z MySQL 4.0 databáze (mysql) do MySQL 4.1 (mysqli).

Požádal jsem tedy webhosting tojeono.cz o vytvoření nové databáze v MySQL 4.1, a zkopírování datových souborů. Problém ovšem byl, že pouhé zkopírování dat nestačí. Tabulky v MySQL 4.0 jsou po převodu do MySQL 4.1 v latin2 kódování (což je hlavní důvod pro úpravu, celý redakční systém jede v UTF-8), a v MySQL 4.1 jsem potřeboval UTF-8. Výsledkem ovšem byla změť znaků, přestože binárně se o unicode jednalo. Nepomohla ani změna typu tabulky z latin2 na binary a poté z binary na UTF-8. PHPMyAdmin zobrazoval pořád nesmyslné znaky.

Jediná cesta, která fungovala, bylo vytvořit novou databázi v MySQL 4.1 s UTF-8 kódováním, exportovat danou tabulku, starou dropnout, vytvořit ji následně znovu, a následně importovat dříve exportovaná data. Za pomoci PHPMyAdmina práce na 10 minut, a web je poté plně fukční, a řadí hezky česky, nicméně, stejně nechápu, proč běžné postupy jako je nastavení COLLATE a CHARACTER SET nefungují, a tabulku je potřeba fyzicky DROPnout a udělat pomocí CREATE novou.


Komentáře

  1. 1 Zorg 06.12.05, 06:12:11
    FB

    V tomhle nedám dopustit na řádkový klient a hostingy, které poskytnou vzdálený přístup k MySQL. Práce na 5 minut a navíc funguje i pro databáze o velikosti, která neproleze MyAdminem ať už kvůli velikost souboru nebo timeoutu skriptu.

  2. 2 Miroslav Navrátil 06.12.05, 06:12:49
    FB

    Radku, mohl bys prosím napsat i článek MySQL 4.1 -> 4.0? Docela by se hodil, jelikož na hostingu mám 4.0 a na lokále 4.1 (latin2).

  3. 3 pif 06.12.05, 06:12:57
    FB

    taky nechápu... obdobné problémy. Ví někdo proč?

  4. 4 kecinzer 06.12.05, 07:12:02
    FB

    Má nějaký význam přecházet na MySQL 4.1, když už je finální verze MySQL 5 ve verzi 5.0.16?

  5. 5 Radek Hulán 06.12.05, 07:12:18
    FB

    [4] samozřejmě, MySQL 5.0 je zatím nepoužitelná (podpora pro VIEWS a TRIGGERS je sice pěkná, ale tipoval bych si, že i bugová, to raději použiji PSQL), kdežto MySQL 4.1 nabízí stále svoji primitivost, ale i stabilitu a funkční podporu pro kódování.

  6. 6 kecinzer 06.12.05, 08:12:22
    FB

    [5] Views a pod. samozřejmě nevyužívám, ale když už tu tahle verze je, tak proč na jí nepřejít. Stejně to bude v budoucnu potřeba.

  7. 7 Jirka 06.12.05, 10:12:33
    FB

    Tak mě napadlo, co třeba udělat porovnání MySQL a Firebird.. zajímalo by mě, jak na tom jsou výkonově apod..

  8. 8 dENIS 06.12.05, 11:12:07
    FB

    Já jsem stejný problém řešil nedávno taky, web jsem psal v UTF-8 data se ukládala do mysql 4, no a na psu se rozhodli pro upgrade a přelili mi databázi z 4 do 4.1. Výsledkem bylo nesmyslné abecední řazení a v myadminu rozsypaný čaj. Když jsem chtěl, ať mi data dumpnou na konzoli, ať je můžu nahrát do nově vytvořených tabulek, tak mi poslali sql soubor s rozsypaným čajem.
    Asi to sprostě vyexportovali v myadminu (což zvládnu taky). Takže zatracená ruční práce s nahrazováním rozdrbané diakritiky sql souboru v texťáku a následný import do nových tabulek...

  9. 9 Milo Kmeť 07.12.05, 08:12:36
    FB

    [7] Na root.cz bolo pred nedávnom porovnanie. To prvé je trošku komické a to opravné už trošku lepšie.

  10. 10 Jakub Vrána 07.12.05, 09:12:38
    FB

    Vysvětlení a řešení problému: Převod kódování MySQL.

  11. 11 horak jan 07.12.05, 09:12:55
    FB

    [8] psa nemam rad hostuji tam taky sice totalni **** protoze jsem si nenasel cas vytvorit neco sam sobe ale to ze tam nemaji php 5 a ani nevi kdy ho budou davat nemluve o mysql 5 mna zacina pit krev nemyslim si ze je pri jejich velikosti takovy problem mit jeden stroj s temito instalacemi...

  12. 12 Radek Hulán 07.12.05, 12:12:32
    FB

    [10] já myslím, Jakube, že píšeš o něčem jiném. Převod z latin2 na binary a poté na utf8 jsem udělal, ale data se zobrazovala pořád špatně, až po DROP a CREATE table a importu dat to bylo ok. Jinak řečeno, tvůj skript jsem na pár tabulkách z 4.0->4.1 vyzkoušel ručně, a nefungoval.

  13. 13 Jakub Vrána 07.12.05, 12:12:57
    FB

    [12] V článku píšeš změna typu tabulky. Můj článek je o tom, že nestačí změnit typ tabulky, ale je potřeba změnit typ všech sloupců. Kromě toho je potřeba samozřejmě mít ve skriptech správně nastavené SET CHARACTER SET (pokud není správně nastavený default).

  14. 14 Radek Hulán 07.12.05, 01:12:09
    FB

    [13] "změnou typu tabulky" myslím samozřejmě i sloupce v dané tabulce, nefunguje to. Jediné co fungovalo je DROP a CREATE. Ověřeno mnou i supportem na webhostingu.

  15. 15 kruxi 07.12.05, 11:12:51
    FB

    MySQL 4.1 je první verze MySQL, která rozlišuje kódování. Interně pracuje v UTF-8, ve kterém má také všechny databáze. Při nahrávání databáze stačí MySQL říct, v jakém kódování je dump. Náslečně při používání databáze stačí říct v jakém kódování s MySQL chcete pracovat.

    Když jsme začínali zhruba před rokem s MySQL 4.1, měli jsme s převody podobné problémy... Pokud si MySQL klient (např. phpMyAdmin) nastavíte na češtinu a latin2 a nahráváte tam dump, který je reálně v UTF-8 (bez znakových definic, které dump z MySQL 4.0 stejně nemá), pak je výsledkem rozsypaný čaj...

    Ke stabilitě MySQL 5 souhlasím s Radkem. Ona ani stabilita MySQL 4.1 není žádný zázrak... ;(

  16. 16 vlado 09.12.05, 10:12:29
    FB

    Zdravim vsetkych, viem ze toto bude asi mimo clanku ale vazne potrebujem pomoc s UTF-8, teraz som v gruzinsku a musim urobit jednoduchy forum pre univerzitu a nefunguje mi spravne UTF-8 na localhoste. Problem je, ze ked pridavam nejake udaje cez phpAdmina tak toto phpAdmin zobrazuje spravne ale moj php-script nie, naopak ked udaje vkladam do databaze cez moj script tak script zobrazuje udaje spravne ale phpAdmin vypisuje nejake nezrozumitelne znaky (to iste sa stava i s rustinou). Za vseliaku pomoc dakujem, Vlado.
    PS: moje nastavenia - collation: utf_general_ci, character set: UTF-8 Unicode (utf8)