Добре дошли!

Добре дошли в нашите форуми, пълни с полезна информация. Имате проблем с компютъра или телефона си? Публикувайте нова тема и ще намерите решение на всичките си проблеми. Общувайте свободно и открийте безброй нови приятели.

Моля, регистрирайте се за да публикувате тема и да получите пълен достъп до всички функции.

ORACLE кирилица

Последователи

Нова тема
Отговор в тази тема

27 октомври 200619 г.

Проблемът е следният: чрез MSQuery от Офис Пакета на Майкрософт правя селект от база данни на ORACLE, която е на друг компютър. Всички данни които са на Кирилица излизат с някакви букви и символи на латиница, на компа на който е инсталиран ORACLE (Windows 2003 Server) всичко е ОК. Пробвах и с една друга Добавка за ЕКСЕЛ SQL*EXCEL ама и там е положението е същото. Копирах FontSubstitutes от Сървъра на XP-то и това също не помогна. Инсталирал съм всички възможни Шрифтове на WIndows и регионалните настройки и на двата Компа са еднакви, също съм копирал всички Шрифтове които ги има на Сървъра а липсваха на XP-то.

Някой има ли идей какво още да опитам? :wors:

Цитирай

27 октомври 200619 г.

Офис пакетите еднакви ли са?

Цитирай

27 октомври 200619 г.

Автор

Офис пакетите еднакви ли са?

да, Офис 2003 BG пълна инсталация и на двете машини

Цитирай

27 октомври 200619 г.

Пробвай да отметнеш настройката "Конфигурация на съвместимост". Не знам как ше е на английски.

Цитирай

27 октомври 200619 г.

Автор

Това не помогна

Цитирай

27 октомври 200619 г.

виж кодировката по-принцип ако колоната с кирилицата има тип nvarchar2 тогава е с uft кодировка, виж виж по настройките на офиса как са кодировките

Цитирай

27 октомври 200619 г.

Автор

виж кодировката по-принцип ако колоната с кирилицата има тип nvarchar2 тогава е с uft кодировка, виж виж по настройките на офиса как са кодировките

Къде по точно в Офиса, защото той си е настроен за БГ от "Езикови настройки на Офис"

А за Базата данни, ако беше от там нямаше ли и на двата компа да не работи?!

Цитирай

28 октомври 200619 г.

Как по-точно правиш връзката между MSQuery и базата данни? Каква кодова таблица ползваш на базата?

select * from nls_database_parameters

Ето примерни стойности на някои от параметрите, които са интересни в случая (най-важният от които е NLS_CHARACTERSET):

NLS_LANGUAGE							 AMERICAN

NLS_TERRITORY							AMERICA

NLS_CHARACTERSET						 CL8MSWIN1251

По принцип има и други допустими кодови таблици, които поддържат кирилица.

На клиентската машина - ако все още нямаш инсталиран Oracle Client на нея - инсталираш и правиш връзката през него. Конфигурирай си връзка към базата и се вържи с sqlplusw; пробвай някоя заявка директно от sqlplusw, за да видиш дали кирилицате е OK.

1) влизаш в Windows Registry: HKLM\Software\Oracle (или нещо подобно) - и търсиш параметри с име NLS_LANG.

2) Редактираш стойността на въпросната променлива на: AMERICAN_AMERICA.CL8MSWIN1251 (може и BULGARIAN_BULGARIA.CL8MSWIN1251). /защото по принцип Windows ползва 1251 за българската кирилица; за някои случаи може и AL32UTF8 да свърши работа/

Не е задължително кодовите таблици на сървъра и на клиента да са еднакви - ако са различни Oracle клиентът би трябвало да извърши необходимата конверсия. Някои кодови таблици не поддържат кирилица (напр. US7ASCII).

3) Понякога се налага и рестартиране на Windows.

4) Пробвай пак през sqplusw дали работи кирилицата. Когато проработи - пробвай през MsQuery дали кирилицата работи вече.

Редактирано 28 октомври 200619 г. от divak (преглед на промените)

Цитирай

28 октомври 200619 г.

Автор

Как по-точно правиш връзката между MSQuery и базата данни? Каква кодова таблица ползваш на базата?
select * from nls_database_parameters

Ето примерни стойности на някои от параметрите, които са интересни в случая (най-важният от които е NLS_CHARACTERSET):

NLS_LANGUAGE							 AMERICAN

NLS_TERRITORY							AMERICA

NLS_CHARACTERSET						 CL8MSWIN1251
По принцип има и други допустими кодови таблици, които поддържат кирилица.

На клиентската машина - ако все още нямаш инсталиран Oracle Client на нея - инсталираш и правиш връзката през него. Конфигурирай си връзка към базата и се вържи с sqlplusw; пробвай някоя заявка директно от sqlplusw, за да видиш дали кирилицате е OK.
1) влизаш в Windows Registry: HKLM\Software\Oracle (или нещо подобно) - и търсиш параметри с име NLS_LANG.
2) Редактираш стойността на въпросната променлива на: AMERICAN_AMERICA.CL8MSWIN1251 (може и BULGARIAN_BULGARIA.CL8MSWIN1251). /защото по принцип Windows ползва 1251 за българската кирилица; за някои случаи може и AL32UTF8 да свърши работа/

Не е задължително кодовите таблици на сървъра и на клиента да са еднакви - ако са различни Oracle клиентът би трябвало да извърши необходимата конверсия. Някои кодови таблици не поддържат кирилица (напр. US7ASCII).
3) Понякога се налага и рестартиране на Windows.
4) Пробвай пак през sqplusw дали работи кирилицата. Когато проработи - пробвай през MsQuery дали кирилицата работи вече.

През SQLPLUSW кирилицата работи, но когато се опитам да копирам нещо директно от там в Ексел данните се скапват. До сега процедирах по следния начин: записвам това което ми трябва в СПООЛ файл и после до импортирам в ЕКСЕЛ. Но смятам че директно в ЕКСЕЛ ще ми е по удомно и по бързо, именно затова се опитвам да по направя така.

А това са database_parameters

SQL> select * from nls_database_parameters;

PARAMETER |VALUE

------------------------------|----------------------------------------

NLS_LANGUAGE |AMERICAN

NLS_TERRITORY |AMERICA

NLS_CURRENCY |$

NLS_ISO_CURRENCY |AMERICA

NLS_NUMERIC_CHARACTERS |.,

NLS_CHARACTERSET |WE8ISO8859P1

NLS_CALENDAR |GREGORIAN

NLS_DATE_FORMAT |DD-MON-RR

NLS_DATE_LANGUAGE |AMERICAN

NLS_SORT |BINARY

NLS_TIME_FORMAT |HH.MI.SSXFF AM

NLS_TIMESTAMP_FORMAT |DD-MON-RR HH.MI.SSXFF AM

NLS_TIME_TZ_FORMAT |HH.MI.SSXFF AM TZR

NLS_TIMESTAMP_TZ_FORMAT |DD-MON-RR HH.MI.SSXFF AM TZR

NLS_DUAL_CURRENCY |$

NLS_COMP |BINARY

NLS_LENGTH_SEMANTICS |BYTE

NLS_NCHAR_CONV_EXCP |FALSE

NLS_NCHAR_CHARACTERSET |AL16UTF16

NLS_RDBMS_VERSION |9.0.1.1.1

20 rows selected.

Редактирано 28 октомври 200619 г. от nikola_n (преглед на промените)

Цитирай

28 октомври 200619 г.

NLS_CHARACTERSET |WE8ISO8859P1

Този characterset не поддържа кирилица. Ако се ползва кирилица бих посъветвал за миграция към такъв, който поддържа... В случая особеното е, че успяваш изобщо да прочетеш кирилицата с sqlplusw (сигурно Oracle клиентът е настроен на WE8ISO8859P1 - така ли е?), а не това че някъде не работи.

Кажи, ако не те устройва вариантът с миграцията на charset-а в базата - все пак може и да е възможно да се измисли нещо.

Цитирай

28 октомври 200619 г.

Автор

Този characterset не поддържа кирилица. Ако се ползва кирилица бих посъветвал за миграция към такъв, който поддържа... В случая особеното е, че успяваш изобщо да прочетеш кирилицата с sqlplusw (сигурно Oracle клиентът е настроен на WE8ISO8859P1 - така ли е?), а не това че някъде не работи.
Кажи, ако не те устройва вариантът с миграцията на charset-а в базата - все пак може и да е възможно да се измисли нещо.

сигурно Oracle клиентът е настроен на WE8ISO8859P1 - ТАКА Е!

Всъщност не ме устройва, защото главната задача на ORACLE е да работи с една ERP система, която не зная как ще се отнесе към промяната. Не искам да променям нищо по сървъра.

Цитирай

28 октомври 200619 г.

сигурно Oracle клиентът е настроен на WE8ISO8859P1 - ТАКА Е!

Всъщност не ме устройва, защото главната задача на ORACLE е да работи с една ERP система, която не зная как ще се отнесе към промяната. Не искам да променям нищо по сървъра.

Ами тогава значи, че не е правилно въпросната база да работи с кирилицата... Т.е. Oracle официално не го поддържа (т.е. ако не работи вината не е в Oracle). Но практиката показва, че някои системи по спецификация изискват конкретен charset и може би случаят е такъв. Все пак, съветът ми е тогава да се говори със поддръжката на ERP системата дали може да се смени charset-ът (пък това дали е възможно и дали/кога ще се изпробва е друг въпрос). Вероятно (ще) имате проблеми и с dblink-ове с други Oracle-ски бази (ако някой ден се стигне до ползване на такива) - аз съм правил опити за борба с такива при US7ASCII и съм стигнал до извода, че е невъзможно да се подкарат (въпросният проблем се заобикаля като не се ползва dblink). Нормално е въпросният workaround да ползвате един и същ charset на базата и на клиента (за да не се извършва "прецакваща кирлициата конверсия") не винаги да върши работа.

Все пак, ако срещна някакво възможно решение на въпросния проблем ще го постна тук. Въпросното MSQuery какъв интерфейс ползва за връзка с базата: ODBC, OleDb...? Пробвай някой друг инструмент през същия интерфейс и виж как се държи (пробвай например с това http://gpoulose.home.att.net/).

Редактирано 28 октомври 200619 г. от divak (преглед на промените)

Цитирай

28 октомври 200619 г.

Ето малко инфо по въпроса:

ODBC and NLS Related Things to Know:
------------------------------------

* From ODBC 8.1.7.2.0 drivers onwards it's NOT possible any more to
"disable" Characterset conversion by specifying for the NLS_LANG
the same characterset as the database characterset. There is now
ALWAYS a check to see if a codepoint is valid for that characterset.
Typically you will encounter problems if you upgrade an environment
that has NO NLS_LANG set on the client (or US7ASCII) and the database
was also US7ASCII. This *incorrect* setup allowed you to store characters
like èçàé in an US7ASCII database, with the new 8i drivers this is not possible
any more. The solution is to correct your NLS setup as described in :

Note 225938.1 Database Character Set Healthcheck

Т.е., ако ползваш ODBC (не знам дали е възможно да не ползваш такова с MSQuery) вероятно ще ти трябва клиент по-стар от посочената версия, за да не се извърши "прецакваща-кирилицата конверсия".

Цитирай

Добавете отговор

Можете да публикувате отговор сега и да се регистрирате по-късно. Ако имате регистрация, влезте в профила си за да публикувате от него.

Публикацията ви съдържа термини, които не допускаме! Моля, редактирайте съдържанието си и премахнете подчертаните думи по-долу. Ако замените букви от думата със звездички или друго, за да заобиколите това предупреждение, профилът ви ще бъде блокиран и наказан!

Напишете отговор в тази тема...