[ОТВЕТИТЬ]
30.01.2012 11:08
Mr_Vito
 
при наценивании накладной, супермаг стал на компьютерах вылетать с ошибкой:

----- Прерывание работы программы -----
сообщение: "ORA-01801: формат даты слишком велик для внутреннего буфера
ORA-06512: на "SUPERMAG.PCLOSE", line 132
ORA-06512: на "SUPERMAG.SMGETCLOSEDDATE", line 5
ORA-06512: на "SUPERMAG.INSPECT", line 658
ORA-06512: на "SUPERMAG.INSPECT", line 787
ORA-06512: на line 1
ORA-06512: на "SUPERMAG.INSPECT", line 315
ORA-06512: на "SUPERMAG.DOCUMENTS", line 3530
ORA-06512: на "SUPERMAG.SMDOCSTATEACCEPTWI", line 13
ORA-06512: на line 1
"
исключение: Sm.Core.InteropException
hResult: 80040E07h; доп. код: 1801
источник: Microsoft OLE DB Provider for Oracle

----- Причина исключения, уровень вложения 1 -----
сообщение: "begin SuperMag.SMDocStateAcceptWI('ПН3037117'); end;"
исключение: Sm.Core.InteropException
hResult: 80004005h; доп. код: 0
источник: SmLibaryBase trace

лечится перезагрузкой рабочей станции, после этого некоторое время всё нормально, потом снова та же фигня :(

подскажите, куда копать?

СМ: 28.2 сп10
ОС: winxpsp3
02.02.2012 14:32
Mr_Vito
 
У умных людей интересовался, пока мне единственное прислали вот это:

I run an client\server application called PVCS. The server is an NT server running an Oracle 8.7.1 runtime database. The clients connect to this via a GUI (Oracle Forms).
Occassionally (every 3 months or so) they get the following error message:

1019-DBIO: ORACLE Error occurred
SQL-0438(00EAF460)ORA-01801: date format is too long for internal buffer.

The only way to solve this is to re-boot the client PC.
I know what the Oracle docs say the error is about, but was wondering if anybody explain it a bit more, especially why re-booting seems the only solution. Is the application wrong, or prehaps the OS, or even the machine heap. I am guessing here - any help would be appreciated.

Ответ:

Generally this error occurs when you have some really long literals in date field. Try looking at the code and your client machine setting may be its converting the date field value. I am not sure but I remember there was some oracle bug also related to this problem. Go to metelink and see if you can find some info.
Error goes away aftet rebooting because you clear the cache and that eliminates the problem.


все таки в чём у меня проблема?
02.02.2012 14:37
Mtirt
 
Формат представления даты клиентского компьютера попробовать поменять?
02.02.2012 14:47
Mr_Vito
 
забыл написать
на раб станции стоят:
report-сы 6.0.8.18
и девяточный слиент 9.2.0.1
02.02.2012 14:52
OlegON
 
давно бы 10ку попробовал... и в %PATH% чтобы пути 10ки первыми были.
03.02.2012 10:43
Mr_Vito
 
переустановил клиента оракла и репортсы
теперь стоит report-сы 6.0.8.18
и рантайм 10.2.0.4
ситуация не изменилась, всё тоже самое :(
пути проверил, 10-ка первой стоит
формат даты в настройках винды менял, не помогает
что еще можно сделать?
03.02.2012 10:59
OlegON
 
а только на одной машине или на всех россыпью это?
03.02.2012 11:07
Mr_Vito
 
россыпью
тот кто много документов редактирует у того и случается
единственное, я пока не засекал через сколько документов эта ошибка выскакивает
но промежуток времени зависит именно от интенсивности корректировки накладных
(т.о. страдает в основном отдел ценообразования и дежурный в торговом отделе, т.к. дежурные разные, то и на разных компах)
03.02.2012 11:08
Mtirt
 
А если попробовать пересоздать профиль пользователя в windows?
03.02.2012 11:17
OlegON
 
можно и oracle пропатчить... клиентский. до 10.2.0.5
03.02.2012 11:20
Mr_Vito
 
я сделаю, но сомневаюсь, что поможет, т.к. и с девяткой тоже самое :(
и вообще винду переставлю :(
03.02.2012 12:04
Mtirt
 
Я подозреваю, что речь вот об этом внутреннем буфере:
20.02.2012 09:58
Mr_Vito
 
во общем проблема решилась, благодаря ораклисту из С+ (спасибо ему)
оказалось, что язык базы данных:
AMERICAN_AMERICA.CL8MSWIN1251
а в реестре на клиентских машинах было прописано:
RUSSIAN_CIS.CL8MSWIN1251

после того как пере прописал в реестрах на клиентах кодовую страницу, супермаг вылетать перестал :)
20.02.2012 10:13
OlegON
 
Очень смешно. Баг Супермага записали? Так и еще багов наловить недолго. Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения и на клиентах должно быть RUSSIAN_CIS. Пусть СМ не пхает мусор. У тебя сейчас могут начаться танцы с точками и запятыми.

Кстати, в 2003м где-то от этого падал почтовик.
Для примера можно еще удивиться английскому написанию месяцев в select sysdate from dual (у тебя есть самописные отчеты?), потом куча геморроя будет, если есть какой-это тупенький экспорт-импорт, где есть дробные числа (привет, каша с десятичным разделителем). В общем, я категорически против америки на клиенте. И ровно настолько категорически за америку на сервере.
20.02.2012 16:05
deepdiver
 
Цитата:
OlegON Очень смешно. Баг Супермага записали? Так и еще багов наловить недолго. Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения и на клиентах должно быть RUSSIAN_CIS. Пусть СМ не пхает мусор. У тебя сейчас могут начаться танцы с точками и запятыми.

Кстати, в 2003м где-то от этого падал почтовик.
Для примера можно еще удивиться английскому написанию месяцев в select sysdate from dual (у тебя есть самописные отчеты?), потом куча геморроя будет, если есть какой-это тупенький экспорт-импорт, где есть дробные числа (привет, каша с десятичным разделителем). В общем, я категорически против америки на клиенте. И ровно настолько категорически за америку на сервере.
Олег, я не уверен что это баг СМ+, т.к. текущий опыт других организаций показывает что такой ошибки не возникает при соответствии кодировок.
По этому работая Mr_Vito исследовал разные варианты и в итоге выяснили что проблема в несовпадении кодировок базы и клиента.
В итоге получалось у БД формат даты ММ.ДД.ГГГГ, а у клиента ДД.ММ.ГГГГ. и для объективности прошу приводить примеры и результат, а не общие слова которые все видят выше.
В результате имеем решенную конкретную проблему, и этот опыт в будущем думаю поможет кому то не мучится долго и не лезть в дебри.

Предполагаю одно из не главных предназначений этого форума в том что бы помогать решать такие не совсем понятные проблемы, которые так и говорят - "а свали на производителя ПО, пусть он решает проблему, но не на самого себя который что то неправильно сделал".
Предлагаю быть более объективным насколько возможно в этом субъективном мире, а не обвинять всех и вся.
20.02.2012 16:27
OlegON
 
Я максимально объективен. Цитирую результаты запросов, получаемых на клиенте в результате установки америки.

Цитата:
SQL> select sysdate from dual;
SYSDATE
---------
20-FEB-12

SQL> select to_char(sysdate,'DD MONTH YYYY') from dual;

TO_CHAR(SYSDATE,'DDMONTHYYYY')
---------------------------------------------------
20 FEBRUARY 2012

SQL> select 1/2 from dual;

1/2
----------
.5
проблема не в том, что мне не нравится, что производитель ПО предлагает клиенту ставить костыль, как в данном случае, а в том, что этот костыль может потребовать кучу дополнительных костылей, потому, что он кривой...
Основной тезис я написал выше: "Разница в языковых установках между сервером и клиентом не должна влиять на работоспособность приложения". Прошу привести доводы в пользу твоего высказывания, что Mr_Vito что-то неправильно сделал. Что именно? Я без наезда потому, что данную проблему не решал, но хочу открыть для себя что-то новое, чего, как думаю, на самом деле не происходило.
Я подозреваю, что где-то в коде СМ дата передалась, как строка, а не как дата, избежав соответствующей конверсии. В результате и получалась дуля с маслом, а не результат. Это я и называю багой.
12.06.2013 05:30
Tiger
 
Не получается решить проблему, с помощью решения предложенного выше! Причем ошибка появляется на разных компьютерах, ОС -Windows 7! Может появились иные способы решения этого бага?
Миниатюры
Нажмите на изображение для увеличения
Название: Ошибка.jpg
Просмотров: 401
Размер:	171.1 Кб
ID:	2032  
12.06.2013 10:44
Troll
 
А что говорит вывод запросов выше в sqlplus на клиенте? Как NLS выставлял?
13.06.2013 04:01
Tiger
 
Цитата:
Troll А что говорит вывод запросов выше в sqlplus на клиенте? Как NLS выставлял?
NLS_LANG исправил в реестре, там где встречалось RUSSIAN_CIS.CL8MSWIN1251 заменил на AMERICAN_CIS.CL8MSWIN1251!

Вот результат выполнения команд (на 1-ом скриншоте - RUSSIAN_CIS.CL8MSWIN1251, на 2-ом - AMERICAN_CIS.CL8MSWIN1251)
Миниатюры
Нажмите на изображение для увеличения
Название: RUSSIAN.jpg
Просмотров: 366
Размер:	51.5 Кб
ID:	2036   Нажмите на изображение для увеличения
Название: AMERICAN.jpg
Просмотров: 363
Размер:	90.1 Кб
ID:	2037  
17.06.2013 11:17
OlegON
 
Чем закончилось? Предлагаю, кстати, всегда менять NLS_LANG в переменных окружения.
17.06.2013 12:00
Tiger
 
Цитата:
OlegON Чем закончилось? Предлагаю, кстати, всегда менять NLS_LANG в переменных окружения.
Сегодня сделали запрос в БД:

Цитата:
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 CL8MSWIN1251
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM

PARAMETER VALUE
------------------------------ ----------------------------------------
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 10.2.0.4.0

20 rows selected.
Решили поставить для эксперимента AMERICAN_AMERICA.CL8MSWIN1251 вместо CIS поставить AMERICA!
17.06.2013 12:26
OlegON
 
Ничего не понял, если честно... Где и что решили поменять?
17.06.2013 15:35
Tiger
 
Цитата:
OlegON Ничего не понял, если честно... Где и что решили поменять?
Сделали запрос приведенный выше на сервере БД. Заметив среди запрошенных параметров NLS_LANGUAGE=AMERICAN и NLS_TERRITORY=AMERICA. И поменяли на клиентских компах в реестре NLS_LANG на AMERICAN_AMERICA.CL8MSWIN1251, до этого меняли RUSSIAN_CIS.CL8MSWIN1251 на AMERICAN_CIS.CL8MSWIN1251
Опции темы


Часовой пояс GMT +3, время: 12:55.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.