[ОТВЕТИТЬ]
Опции темы
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:46  
OlegON
А клиент 10ки?
 
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?
 
 


Опции темы



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

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