Ing. Ondřej Navrátil napsal(a):
Dobrý den,
mám provázáno OOo Base s MySQL serverem 5.0 přes ODBC driver.
Znakové sady v OOo i MySQL jsou nastaveny na UTF-8, ale OOo zřejmě
nekomunikuje korektně.
Data vkládaná přes OOo jsou do DB vložena a OOo je pak zpětně
přečte - se správnou češtinou .... jen výjmečně se zobrazí hláška "[My
SQL][ODBC 3.51 Driver][mysqld-5.0.19-nt]Data too long for column
'column name' at row 1"
Pokud DB zazálohuji, tak vyexportuje sql soubor kódovaný v UTF-8,
ale se zmršenou češtinou. Pokud v tomto souboru češtinu spravím, anebo
připravím obdobný soubor se správnou češtinou a ten pak zpět
naimportuju tak je v OOo zmršená čeština, ale v souboru z další zálohy
DB je už čeština vpořádku.
Obdobné problémy jsou i při použití kódování CP1250.
Můžete někdo potvrdit problém? Neznáte někdo řešení?
Toto nemusí být jen problém OOo, i když zkušenosti mám podobné. Měl jsem
zajímavý problém na RedHat 9.0 a Mandriva 2006, kdy docházelo ke
komolení češtiny na MySQL serveru. Pro zálohování databáze jsem používal
phpMyAdmina, jehož vygenerovaný sql soubor jsem přenášel mezi dvěma
servery. Když se databáze trošku rozrostla, odmítal mi server jeden
zvlášť dlouhý příkaz naplnění tabulky zbaštit z důvodu překročení
velikosti sql příkazu. pokud jsem ale db zazálohoval v režimu
oddělených sql příkazů (co záznam, to insert into ..), měla záloha
takovou velikost, že ji nechtěl zbaštit php. V té době jsem trochu
tápal, a tak mě napadlo otevřít zálohu přímo z konzole na serveru (tu
dlouhou - bez načítání www serverem) a v tu chvíli se mršila čeština .
Db byla v kódování 8895-2, ale konzole utf-8. Zatímco načtení souboru
zálohy (taky 8859-2) přes webserver + php skript probíhalo bez problémů,
pokud jsem otevřel soubor zálohy v utf-8 konzoli, čeština se rozhodila.
Později jsem ten problém vyřešil zmenou parametrů php ohledně
akceptované délky souboru.
Ještě dříve jsem laboroval s propojením MySQL a OOO ( MySQL na RedHatu,
OOo na WinXP) ale bylo to v době, kdy měl MySQL ještě problémy s
různými kódovými stránkami, ooo 2 se sotva klubal na svět, ale
propojení mi problémy nedělalo. Když jsem pak totéž zkoušel doma (MySQL
i ooo na stejném stroji Mandrake 10.1), kompatibilita byla mnohem horší.
Kódováni síce v pořádku, ale ale při editaci dat se objevovaly problémy
např. se zadáváním čísel - desetinná tečka se musela psát jako tečka, a
pod. Po těchto zkušenostech jsem další pokusy s oooBase zastavil,
protože to není tvorba, ale patlání. Jako náhrada Accessu (jak o Base
občas vidím psáno) se rozhodně nehodí, snad jen pro ty nejjednodušší
případy. Nicméně je dobré, že Base existuje, alespoň nějakým způsobem
obstaráva práci s daty. A pokud se místo hurá vývoje soustředí tvůrci na
dopilování současných vlastností, mohl by se z Base stát docela
použitelný nástroj. O používání ooo
Sun.com.dispatcher.object.reset.Basicu a dokumentaci k němu ani nemluvě.
S pozdravem Milan Uhrák.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
