У меня есть следующий вопрос к специалистам Oracle.
Согласно рекомендациям Oracle для баз данных межнационального использования, в наших аппликациях мы переводим типы данных с VARCHAR2 на NVARCHAR2 и CHAR на NCHAR, чтобы успешно работать с unicode базами данных, которые имеют database character set равный AL32UTF8 и national character set равный AL16UTF16, с различных клиент-компьютеров, имеющих различные региональные установки (например NLS_LANG=GERMAN_GERMANY.WE8MSWIN1252, NLS_LANG=RUSSIAN_CIS.CL8MSWIN1251, NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 и т.п. с соответствующими значениями параметров Regional and Language Options в Windows операционных системах клиент-компьютеров.
Oказалось, что использование таких типов данных сопряжено с определенными проблемами. Одну из которых я продемонстрирую на примере ниже:
SQL> create table t1 (c1 nvarchar2(50));
Tabelle wurde erstellt.
SQL> insert into t1 values('2');
1 Zeile wurde erstellt.
SQL> select c1 from t1
2 union
3 select '1' as c1 from t1;
select c1 from t1
*
FEHLER in Zeile 1:
ORA-12704: character set mismatch
SQL>
Пример выполнен в SQL*Plus в немецкой среде, но тоже самое получается в русской и американской среде.
Я нашел одно решение этой проблемы, вот оно:
SQL> select c1 from t1
2 union
3 select to_nchar('1') as c1 from t1;
C1
--------------------------------------------------
1
2
SQL>
Но это решение не очень желательно для наших аппликаций по двум причинам:
- мы стараемся писать одинаковый код как для Oracle, так и для Microsoft SQL Server, в котором, кстати, таких проблем с типами данных NCHAR и NVARCHAR нет;
- слишком много мест для изменений в коде аппликаций.
Может быть кому-нибудь известно более элегантное решение этой проблемы ?
Согласно рекомендациям Oracle для баз данных межнационального использования, в наших аппликациях мы переводим типы данных с VARCHAR2 на NVARCHAR2 и CHAR на NCHAR, чтобы успешно работать с unicode базами данных, которые имеют database character set равный AL32UTF8 и national character set равный AL16UTF16, с различных клиент-компьютеров, имеющих различные региональные установки (например NLS_LANG=GERMAN_GERMANY.WE8MSWIN1252, NLS_LANG=RUSSIAN_CIS.CL8MSWIN1251, NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 и т.п. с соответствующими значениями параметров Regional and Language Options в Windows операционных системах клиент-компьютеров.
Oказалось, что использование таких типов данных сопряжено с определенными проблемами. Одну из которых я продемонстрирую на примере ниже:
SQL> create table t1 (c1 nvarchar2(50));
Tabelle wurde erstellt.
SQL> insert into t1 values('2');
1 Zeile wurde erstellt.
SQL> select c1 from t1
2 union
3 select '1' as c1 from t1;
select c1 from t1
*
FEHLER in Zeile 1:
ORA-12704: character set mismatch
SQL>
Пример выполнен в SQL*Plus в немецкой среде, но тоже самое получается в русской и американской среде.
Я нашел одно решение этой проблемы, вот оно:
SQL> select c1 from t1
2 union
3 select to_nchar('1') as c1 from t1;
C1
--------------------------------------------------
1
2
SQL>
Но это решение не очень желательно для наших аппликаций по двум причинам:
- мы стараемся писать одинаковый код как для Oracle, так и для Microsoft SQL Server, в котором, кстати, таких проблем с типами данных NCHAR и NVARCHAR нет;
- слишком много мест для изменений в коде аппликаций.
Может быть кому-нибудь известно более элегантное решение этой проблемы ?
Исправлено пользователем Акулов (24.07.07 20:22)