@Balamout

Возникла проблема при миграции из Oracle 7.3
в Oracle 8.17. Клиентское приложение при сохранении форм выдает ошибку ORA 01843, кажется. В общем если быть точным - неверный формат месяца. Просмотрел SYS.PROPS$ проверил формат даты. Вроде все как надо, DD-MON-RR. хотя что есть RR не могу понять, поставил на всякий случай DD.MM.YY. Ничего не изменилось, ошибка прежняя.
Все настройки в Regional Settings, тоже вроде
корректные. Приложение гарантированно должно работать c Oracle 8.05 ;( . Кто-нибудь решал подобную проблему?

0

@etsypin

А как проводилась процедура миграции. В смысле перенос данных.

0

@Balamout

Ну, по всей видимости, не очень правильно
Я выгрузил из старой базы дампы отдельных
юзеров. Установил на новом сервере новый
Oracle, ну и загрузил на нем дампы
соответственно Загрузка прошла успешно,
пользователи прекрасно работали до того
момента, пока им не пришлось сохраняться.
Тогда возник ORA-01843. Я почитал доку ...
Если NLS_DATE = DD-MON-YY то Оракул понимает
JAN, FEB, если MONTH то полное название месяца.
Может дело в том, что клиентские машины с русифицированными ОС? Хотя раньше все работало,
и настройки Oracle 7.3 были по умолчанию ...

0

@etsypin

При импорте/экспорте NLS_DATE,NLS_xxx были выставлен правильно?
Не импортилось ли что нибудь от sys.
Если создать новую таблицу и туда insert то как оно?
И сделать с существующих таблиц селект с поля даты с предобразованием dd.mm.yyyy, и еще куданибудь и без преобразования и сравнить?

Кстати а машинка не под w2k с которой идет обращение если да то используется ли 0040 если да то версия должна быть выше 3.7
Выполнить от sys / as sysdba ?/rdbms/admin/utlrp.sql перекомпиляция объекто но это маловероятно.

Потом попробовать Catalog.sql, catproc.sql, но это уже от результатов предыдущих опытов;

ВОзможен еще вот какой вариант, но тут надо смотреть приложение:

I'm getting all sorts of interesting results here - take a look.
Let's try Paul's suggestion (well spotted by the way):

V7

SQL> insert into date_tab (char_col) values (
2 TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY'));

1 row created.

V8

SQL> insert into date_tab (char_col) values (
2 TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY'));

1 row created.

The corresponding select statements return the same as in the original examples.
Here's what happens if we try a date column:

V7

SQL> insert into date_tab (date_col) values (
2 TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY'));
TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY'))
*
ERROR at line 2:
ORA-01843: not a valid month

V8

SQL> insert into date_tab (date_col) values (
2 TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY'));
TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY'))
*
ERROR at line 2:
ORA-01843: not a valid month

Some consistency at last, but still not what Oracle say will happen.
Here's the last scenario I tried:

V7

SQL> insert into date_tab (date_col) values ('0297');
insert into date_tab (date_col) values ('0297')
*
ERROR at line 1:
ORA-01843: not a valid month

V8

SQL> insert into date_tab (date_col) values ('0297');
insert into date_tab (date_col) values ('0297')
*
ERROR at line 1:
ORA-01861: literal does not match format string

Well, we finally found the ORA-01861, but what about the V7 behaviour?

В общем успехов

0

@Balamout

Ну, это все я проверил
Оракул мой все прекрасно понимает в форматах DD.MM.YY,DD.MM.YYYY, MM/DD/YY и DD-мес-YY,
Можно ли мне как нибудь просмотреть что же именно SQL формирует клиентское приложение, что возникает ошибка ORA 1843?? Разработчики сами не помнят каким образом они формируют запросы
Может ли Оракул вести подобные подобные логи?

0

@etsypin

Может но смотреть их полный бред. Надо для сессии сказать alter session ... sql_trace=true вроде так точно не помню. а далее на сервере создается лог потом смотреть полученный лог.

0

@Balamout

Огромное спасибо ... Промучившись целую субботу запустил SQL trace, ну и .. решил все проблемы .. Приложение сохраняет даты в формате DD-Мon-YYYY
а оракул понимал только DD-Мес-YYYY, все залечилось установкой
NLS_LANG = AMERICAN_AMERICA.CL8MSWIN1251.
как на серверной, так и на клиентской стороне..
Вообще это глюк разработчиков, они должны были подчеркнуто отразить эту деталь в документации ....

0