2010-10-27 2 views
2

Наш класс java вызывает PLSQL-процесс, который возвращает дату в формате по умолчанию, который определяется NLS_DATE_FORMAT. Наше приложение устанавливает свой собственный язык для интернационализации, но я хочу, чтобы формат даты оставался просто «DD-MON-RR», который является en_US Locale NLS_DATE_FORMAT. Из-за изменения выбранной строки даты, выбранной в окошко, и последующих вызовов функции TO_DATE() не выполняется. Я попытался исправить это, изменив Locale to Locale.setDefault(new Locale("en","US")); //"en_US" в классе java, и он отлично работает, но часть интернационализации больше не работает. Я в Сингапуре, поэтому мой Locale - "en_SG" и формат даты, который предполагает оракул после установки NLS_TERRITORY: SINGAPORE - NLS_DATE_FORMAT:'DD/MM/RR'. Я запрашиваю сервер для V $ NLS_PARAMETERS, и формат даты по умолчанию - «DD-MON-RR». Итак, мой вопрос: могу ли я установить NLS_DATE_FORMAT, не затрагивая настройки локали приложения. Или я могу заставить драйвер jdbc полностью игнорировать настройки NLS клиента?Как установить формат даты NLS без установки Locale

ответ

3

Yo можно использовать to_char функцию для форматирования даты, как вы хотите, также вы можете включить третий параметр в to_char функции для обозначения локаль используется:

select to_char(sysdate, 'DY-MM-YYYY', 'NLS_DATE_LANGUAGE=AMERICAN') from dual; 

Более подробную информацию о форматах дат можно найти в SQL Reference.

+0

О да, на самом деле я мог бы использовать 'TO_CHAR (sysdate, 'DD-MON-RR')' в PLSQL if это было возможно в моем случае. Но мой проект перестраивает часть старого кода PRO C * в java. Поэтому каждый хочет оставить части PL/SQL неизменными, поскольку в настоящее время он работает нормально. Проблема возникла, поскольку код PRO C * лежит на том же компьютере, что и в базе данных, поэтому они выполняют те же настройки NLS. Но этот Java-класс может быть частью сервера приложений, и в будущем он, скорее всего, перейдет в веб-службу. Поэтому я хочу сохранить существующие настройки Locale, так как приложение также отлично работает в настоящее время. –

0

Я вроде финализации на i18n вещи для моего приложения, и мой дизайн основан на предположениях ниже)

1) Locale.setDefault (новый Locale («ан», «US»)); плохо, поскольку вы меняете стандартную локаль для JVM, а не только для своего приложения. Поэтому лучше передать локаль вокруг приложения на основе запроса (может быть threadlocal)

2) Обрабатывать все форматирование/синтаксический анализ i18n на уровне приложения. БД должна обрабатывать только сравнения (необязательно), сортировку (необязательно) и хранение. Поэтому просто установите NLS_CHARACTERSET, NLS_COMP, NLS_SORT и NLS_LENGTH_SEMANTICS. Кстати, сравнение и сортировка на уровне db означает создание индексов, специфичных для локали, таким образом замедляя вставки/обновления.

+0

Да, ваша первая точка верна. Для второй точки у нас есть форматирование i18n в интерфейсе, но процедура возвращает данные из строки из процедуры oracle. Более простой код, как формируется строка, подобен 'select 'MKDT' || lpad (nvl (length (por.maker_date), 0), 3, '0') || por.maker_date данные из TABLEXYZ;' Я предполагаю, что это строка автоматически вызывает 'TO_CHAR (, )' и преобразует дату. Я знаю, что они должны были использовать 'TO_CHAR (, <СПЕЦИФИЧЕСКИЙ ФОРМАТ ДАТЫ>)'. Я уже предлагал сделать это изменение в DB Procs, но это связано с большим количеством изменений в стабильной PROCS. –

Смежные вопросы