MySql 4.0 vs. 4.1

[Peter Rosa]

Zdravim,

> Po pripojeni pouzivaj prikazy:
> 
> /*!40101 SET NAMES=cp1250 */
> /*!40101 SET COLLATION=cp1250_general_ci */
> 
> a mas to spatne kompatibilne v tvojich aplikaciach. Podla mna je podpora
> charsetov v MySQL dobre a lezu mi na nervy ludia, ktori stale nad tym
> fnukaju, namiesto toho, aby si precitali vybornu dokumentaciu na
> dev.mysql.com. Bez toho aby clovek trosku rozumel tomu, ako uklada data
> do db sa to fakt neda robit spravne.

vsak ja si netrufam tvrdit, ze to nie je dobra vec. Horsie je, ze to
este nikto nepovedal providerom :-)  Ked to konecne upgraduju aj oni,
tak to mozeme urobit aj my.  Ale teraz by ma to stalo privela casu
(ktory uz aj tak nemam)... Inak, nastudoval (a dokonca aj pochopil)
som to uz davnejsie, cize to nie je o nechapani/lenivosti :-) ale o
minimalizacii rizik a zbytocnej prace naviac.

Otazka skor znie, ci nie su problemy pri exporte z 4.1 (5.x) a naslednom
importe do 4.0? Povedzme, ze v 5.1 databaze mas data ukladane v UTF-8
a chces to dostat do databazy u providera, kde je mysql 4.0.20 a
phpmyadmin 2.5.7 (ktory o nejakych triedeniach ani netusil), pricom 
stranky mas kodovane v cp1250. Co sa presne stane s diakritikou? A co sa 
stane s tabulkou, v ktorej su data v rustine (cp1251)? Toto su otazky, s 
ktorymi si lamem hlavu...

Dalej, len na testovacom serveri mam 15 databaz, cca 300 tabuliek
a cca 130 MB dat v nich. Ako mam v *rozumnom* case nastavit kazdej DB,
kazdej tabulke a kazdemu stlpcu charset/triedenie tak, aby som o tie
data neprisiel (resp. aby mi ich to neprekodovalo do CP, z ktorej to
uz nazad nedostanem)?
Toto je hlavny dovod,  preco patram po nastaveniach  "aby sa to navonok
spravalo ako 4.0", cize cela trojica (server/klient/admin) mala default
charset (ktory mu zadam) a nemusel som sa o to starat pri kazdom
importe/exporte / vytvoreni db/tabulky / vlozeni/uprave riadku...

Vdaka za tie prikazy.

Prijemny vecer,

-- 

Peter Rosa