snazim se prijit na to, jak si behem session zmenit kodovani
na chvili na UTF8 z default ISO8859-2 a po par insertech/selectech
zase zpet. Nejak nemuzu na to nic najit, jazyk, trideni, cisla atd
pres alter session set nls_XXX jde, ale znakovou sadu jsem neodhalil.
Nebo budu muset si to vsude rucne ohlidat pres fci convert()?
Majkl
Ono je to soucasti jazyka:
alter session set nls_lang='American_America.ee8iso8859p2';
Jan Serak
Variace na toto jsem vcera zkousel, vzdy jsem dosel akorat k
'ORA-00922: chybějící nebo neplatná volba'. Vami uvedeny radecek
dava stejny vysledek. Ani v definicich jsem nenasel, ze by NLS_LANG
byla u alter session k dispozici. Aspon 'Oracle9i Globalization
Support Guide' o tom cudne mlci.
Jedine funkcne podobne je neco v duchu:
alter session set nls_language='CZECH' nls_territory='CZECH REPUBLIC'
ale nejak dal se mi k tomu uz nepodarilo najit nic na tu znakovou
sadu. :-((
Oracle server i klient 9.2.0.1.0.
Majkl
PS: Jsem se pri te prilezitosti i dival do lokalizacnich souboru
a docela jsem se pobavil. Treba nasi narodni zvyklosti pro psani
zapornych castek je 'Kc 12345,67-'. :-)
Ano. Znakova sada klienta je parametr klienta, nikoliv session. Rikate
mu tim, s jakou znakovou sadou pracuje Vase aplikace (programovaci
prostredi, operacni system) coz Oracle predpoklada, ze se pri behu aplikace
nezmeni.
Asi zalezi na tom, co ve Vasem konkretnim pripade presne potrebujete, ale
myslim, ze obecne by melo byt veci aplikace v jakem kodovani bude data
poskytovat, coz by na zaklade tohoto parametru mela jasne rict a dodrzet.
Vyhodou Oraclu je, ze to nemusi byt nutne to kodovani, ve kterem jsou
ulozena data v databazi a ze data v databazi mohou byt ulozena v kodovani,
ktere nepodporuje operacni system na kterem bezi.
Miroslav Kripac
Oooops, tohle jsem zasklil :-(
V tom pripade si nemusite hrat s ALTER SESSION, protoze mate
k dispozici CONVERT ( char , dest_char_set [ , source_char_set ] )
a touhle si muzete udelat jakoukoli konverzi, kterou zrovna
potrebujete. Napr.
select convert('přísedící','utf8') from dual;
vrati krasne rozsypany caj...
Jan Serak
>
> Majkl
>
> PS: Jsem se pri te prilezitosti i dival do lokalizacnich souboru
> a docela jsem se pobavil. Treba nasi narodni zvyklosti pro psani
> zapornych castek je 'Kc 12345,67-'. :-)
Neni se cemu divit, kdyz to delaji Indove v Irsku ;-)
> > PS: Jsem se pri te prilezitosti i dival do lokalizacnich souboru
> > a docela jsem se pobavil. Treba nasi narodni zvyklosti pro psani
> > zapornych castek je 'Kc 12345,67-'. :-)
>
> Neni se cemu divit, kdyz to delaji Indove v Irsku ;-)
Na strojoch co vyrabaju cinani pre japoncov, ktori pracuju pre
americanov, ktori su kontrolovani zidmi?
:)
A pre koho teda pracuje ceske zastupenie ORACLE(R)? Ked sa nedokaze
podivat na tie nezmysly co su tam zvolene?
--
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)
Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28 (+420 5688384 28)
fax:568 8384 27 (+420 5688384 27)
homepage:http://www.tesnet.cz
Oracle Czech se nepodili na vyvoji RDBMS. Vypada to divne, muzem s tim
dokonce nesouhlasit, ale to je vse, co se proti tomu da delat.
Kolega ted resi problem s generovanim vystupu v PDF z Oracle9i Report
Serveru tak, aby byly spravne cesky. Dostal se pres nejnemoznejsi
managery Oracle Czech az k vyvojarum, ale jsou to Holandan, Dan, Spanel
a Rek. Objevili nekolik zasadnich bugu, kvuli kterym to v nasem
prostredi
jeste dlouho fungovat nebude. Vyvojari z Oracle to uznavaji, v jejich
oficialni evidenci se objevily, ale vsichni lide z Oracle Czech,
nejvyssim
sefem pocinaje a posledni uklizeckou konce jsou schopni se do krve
hadat,
ze neni zadny duvod, proc by se nemohly Oracle9i Forms & Report Servers
nasadit v Cesku do produkcniho prostredi. Ten format zapisu ceske meny
je jenom drobna kosmetika.
Jan Serak
Jan Serak wrote:
>
> martin kluvanek wrote:
> > A pre koho teda pracuje ceske zastupenie ORACLE(R)? Ked sa nedokaze
> > podivat na tie nezmysly co su tam zvolene?
>
> Oracle Czech se nepodili na vyvoji RDBMS. Vypada to divne, muzem s tim
> dokonce nesouhlasit, ale to je vse, co se proti tomu da delat.
No jasne, bral som to skorej ako recnicky exhibisionizmus, ale stejne je
smutne ked nieco predavaju a ani sa nenamahaju podivat, ci udaje o
lokalizacii maju aspon nieco spolocne s realitou.
Napriklad v slovenskej lokalizacii sa pise ze existuje nieco ako pismeno
DZ coz mi asi v skole uniklo.
Ale potom by tam celkom iste malo byt i pismeno UAAA a IIIHA.
>
> Kolega ted resi problem s generovanim vystupu v PDF z Oracle9i Report
> Serveru tak, aby byly spravne cesky. Dostal se pres nejnemoznejsi
> managery Oracle Czech az k vyvojarum, ale jsou to Holandan, Dan, Spanel
> a Rek. Objevili nekolik zasadnich bugu, kvuli kterym to v nasem
> prostredi
> jeste dlouho fungovat nebude. Vyvojari z Oracle to uznavaji, v jejich
> oficialni evidenci se objevily, ale vsichni lide z Oracle Czech,
> nejvyssim
> sefem pocinaje a posledni uklizeckou konce jsou schopni se do krve
> hadat,
> ze neni zadny duvod, proc by se nemohly Oracle9i Forms & Report Servers
> nasadit v Cesku do produkcniho prostredi. Ten format zapisu ceske meny
> je jenom drobna kosmetika.
>
> Jan Serak
--
Ale to je (IMHO) u techto vetsich firem u vsech. Ze v CR je jen
zastoupeni organizujici prendavani krabic a nic vic. Nenepada me
z vetsich firem snad zadna, kde by to tak nejak nebylo.
> Kolega ted resi problem s generovanim vystupu v PDF z Oracle9i Report
> Serveru tak, aby byly spravne cesky. Dostal se pres nejnemoznejsi
> managery Oracle Czech az k vyvojarum, ale jsou to Holandan, Dan, Spanel
> a Rek. Objevili nekolik zasadnich bugu, kvuli kterym to v nasem
> prostredi jeste dlouho fungovat nebude. Vyvojari z Oracle to uznavaji,
> v jejich oficialni evidenci se objevily,
To se da aspon povazovat za male plus, takze casem se to treba vyresi,
nekteri by to prohlasili za vlastnost na ktere nekteri zakaznici
treba trvaji. :-)
> ale vsichni lide z Oracle Czech, nejvyssim sefem pocinaje a posledni
> uklizeckou konce jsou schopni se do krve hadat,
> ze neni zadny duvod, proc by se nemohly Oracle9i Forms & Report Servers
> nasadit v Cesku do produkcniho prostredi.
To se da take pochopit, je to prenasec krabic placeny za mnozstvi
prenesenych krabic!
> Ten format zapisu ceske meny je jenom drobna kosmetika.
Ono tam toho bude vic, kdyz jsem jen tak preletl definice trideni,
tak jsem ani nepostrehl nejake nase lahudky (jako treba ch),
ale mohl jsem se do toho blbe divat.
Majkl
Krucinal. Nejak toho moc predpokladaj. Ani je nenapada takova
trivialnost, ze jedna bezici aplikace v kazdem vlaknu pouziva jiny
jazyk a kodovani, pripadne se to dle faze mesice prubezne meni. :-)
> Asi zalezi na tom, co ve Vasem konkretnim pripade presne potrebujete, ale
> myslim, ze obecne by melo byt veci aplikace v jakem kodovani bude data
> poskytovat, coz by na zaklade tohoto parametru mela jasne rict a dodrzet.
Je to malej modul v perlu do apache, co generuje nejake text soubory
z dat a zase je strka zpet. Tohle jede normalne v ISO8859-2, ale ten
vstupni soubor muze byt i XML a tam prichazi varianta s UTF8, takze
aplikace v zavislosti na tom, co se dal bude dit s daty nebo odkud jsou
musi rozdychat ISO nebo UTF8. Na to by se hodilo to prepinani.
Asi budu muset pouzit tu fci convert(). Pokud "select value$ from
sys.props$ where name='NLS_CHARACTERSET'" opravdu vraci kodovani
pouzite v DB, tak by nemel vzniknout problem. :-)
> Vyhodou Oraclu je, ze to nemusi byt nutne to kodovani, ve kterem jsou
> ulozena data v databazi a ze data v databazi mohou byt ulozena v kodovani,
> ktere nepodporuje operacni system na kterem bezi.
Tohle je prijemna vec.
Majkl
Tohle nemuzu doporucit, protoze PROPS$ neni dokumentovane rozhrani.
Lepe Vam pomuze
SELECT value FROM v$nls_parameters WHERE parameter='NLS_CHARACTERSET';
Dostanete rovnou per-session informaci. O kodovani, ve kterem se to
fyzicky ulozi, se nemusi ten program starat.
Je pravdepodobne, ze Oraclove si tim vyresili nejaky vnitrni problem,
protoze to nejde ani pres ALTER SESSION ani pres dbms_session.
Nikde jsem nenasel explicitni zminku o duvodech (jenom v nejakem howto
na Metalinku, ze v ALTER SESSION lze pouzit vsechny NLS parametry
s vyjimkou NLS_CHARACTERSET).
Proste se nechava se na programu, ze kdyz manipuluje s externimi daty,
ktera
jsou v jinem kodovani, musi holt udelat CONVERT pred ulozenim do
databaze.
Jeste k tomu, co pisete o Apacim modulu a multithreadovych aplikacich.
Predpokladam, ze oboje by se psalo v OCI8 a tam nemoznost zmenit
kodovani pres ALTER SESSION vubec nevadi, protoze to zmenit lze
lowlevel funkci OCIEnvNlsCreate() nebo pouzit session pool (coz je
primo site na multithreading, akorat, kdyz jsem to cetl, tak mi
vstavaly vlasy na hlave vic, nez kdyz jsem cetl povidky od E. A. Poea).
Jan Serak
...
> Jeste k tomu, co pisete o Apacim modulu a multithreadovych aplikacich.
> Predpokladam, ze oboje by se psalo v OCI8 a tam nemoznost zmenit
> kodovani pres ALTER SESSION vubec nevadi, protoze to zmenit lze
> lowlevel funkci OCIEnvNlsCreate() nebo pouzit session pool (coz je
> primo site na multithreading, akorat, kdyz jsem to cetl, tak mi
> vstavaly vlasy na hlave vic, nez kdyz jsem cetl povidky od E. A. Poea).
A neni jednodussi, je-li to cele v Perlu, pouzit na ta XML data standardni
prostredky Perlu pro konverzi ruznych kodovani?
Miroslav Kripac
Spravne ceske trideni vcetne podpory ch je podporovano v tridici sade
XCZECH jiz od verze Oracle 8.0.4 (opravena chyba z 8.0.3) vcetne.
Dusan Bolek