Ошибка при вызове метода контекста (ВыполнитьПакет)
Внимание! Тема закрыта. Добавлять сообщения в закрытую тему запрещено.
Добрый день уважаемые форумчане!
Вчера обновил платформу 8.2, до последней версии 8.2.19.83
Теперь в одной из конфигураций, при проведении документа вылетает ошибка:
Ошибка при выполнении обработчика - 'ОбработкаПроведения'
по причине:
{Документ.уатРемонтныйЛист.МодульМенеджера(468)}: Ошибка при вызове метода контекста (ВыполнитьПакет)
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
ERROR: value "22089890160" is out of range for type integer
CONTEXT: PL/pgSQL function datediff(character varying,timestamp without time zone,timestamp without time zone) while casting return value to function's return type
Показать
Пользователи работают с 1с, через терминал. На сервере установлен сервер 1С и Postgres SQL 9.2.1-1.1C.
По тексту ошибки datediff понял что проблема в вычислении разности дат.
На users уже вышла есть более поздняя версия Postgres.
Что лучше сделать обновить Postgres c надеждой что ошибка исчезнет и как правильнее обновить (еще не обновлял с рабочими базами) или может есть смысл перейти на новую платформу 8.3, возможно на ней будет работать корректно.
Вчера обновил платформу 8.2, до последней версии 8.2.19.83
Теперь в одной из конфигураций, при проведении документа вылетает ошибка:
Ошибка при выполнении обработчика - 'ОбработкаПроведения'
по причине:
{Документ.уатРемонтныйЛист.МодульМенеджера(468)}: Ошибка при вызове метода контекста (ВыполнитьПакет)
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
ERROR: value "22089890160" is out of range for type integer
CONTEXT: PL/pgSQL function datediff(character varying,timestamp without time zone,timestamp without time zone) while casting return value to function's return type
Пользователи работают с 1с, через терминал. На сервере установлен сервер 1С и Postgres SQL 9.2.1-1.1C.
По тексту ошибки datediff понял что проблема в вычислении разности дат.
На users уже вышла есть более поздняя версия Postgres.
Что лучше сделать обновить Postgres c надеждой что ошибка исчезнет и как правильнее обновить (еще не обновлял с рабочими базами) или может есть смысл перейти на новую платформу 8.3, возможно на ней будет работать корректно.
По теме из базы знаний
Найденные решения
(1) cherepawka,
если есть возможность - попробуй для проверки
на тестовой машине развернуть тестовую базу под 8.3.4 с тем же Postgres.
это наверное проще всего будет сделать.
***
сдается, что из-за самого Postgres - это маловероятно.
а можешь запрос выложить (или он из закрытого модуля)?
вдруг, если его подковырнуть правильно - то будет щастье?
если есть возможность - попробуй для проверки
на тестовой машине развернуть тестовую базу под 8.3.4 с тем же Postgres.
это наверное проще всего будет сделать.
***
сдается, что из-за самого Postgres - это маловероятно.
а можешь запрос выложить (или он из закрытого модуля)?
вдруг, если его подковырнуть правильно - то будет щастье?
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) cherepawka,
если есть возможность - попробуй для проверки
на тестовой машине развернуть тестовую базу под 8.3.4 с тем же Postgres.
это наверное проще всего будет сделать.
***
сдается, что из-за самого Postgres - это маловероятно.
а можешь запрос выложить (или он из закрытого модуля)?
вдруг, если его подковырнуть правильно - то будет щастье?
если есть возможность - попробуй для проверки
на тестовой машине развернуть тестовую базу под 8.3.4 с тем же Postgres.
это наверное проще всего будет сделать.
***
сдается, что из-за самого Postgres - это маловероятно.
а можешь запрос выложить (или он из закрытого модуля)?
вдруг, если его подковырнуть правильно - то будет щастье?
(2) cherepawka,
а ошибка валится при проведении любого путевого листа
или как-то выборочно ???
PS
еше у серверных баз есть свойство:
Информационная база (IInfoBaseInfo)
DateOffset (DateOffset)
Использование:
Только запись.
Описание:
Тип: Число.
Смещение дат в информационной базе (0 или 2000).
Доступность:
Интеграция.
Показать
от него тоже может что-то зависить.
а ошибка валится при проведении любого путевого листа
или как-то выборочно ???
PS
еше у серверных баз есть свойство:
Информационная база (IInfoBaseInfo)
DateOffset (DateOffset)
Использование:
Только запись.
Описание:
Тип: Число.
Смещение дат в информационной базе (0 или 2000).
Доступность:
Интеграция.
от него тоже может что-то зависить.
Похожая ошибка на ЗУП Бюджета у меня вываливается на DB2. Нашел и устранил следующим образом. В режиме отладки выяснил, какой запрос дает ошибку (сделал несколько точек останова). Нашел запрос. Он из нескольких запросов с временными таблицами. Сделал этот запрос в консоли запросов, добавляя по одной временные таблицы. Так нашел запрос где из Даты NULL или Даты(01,01,001) вычиталось еще что-то (1 сек). Ну и модифицировал запрос через ВЫБОР. Вот такой алгоритм. Причем, на файловом варианте и MS SQL - все было ок
Проблема решилась. Все оказалось намного проще, пользователь неправильно указал период ремонта в документе, а в запросе рассчитывалась разность дат в секундах, от такого числа секунд, 1с выдавало ошибку.
Думаю что никто не будет против, если первому откликнувшемуся, перечислю вознаграждение- Rothschild . Всем спасибо за помощь.
Думаю что никто не будет против, если первому откликнувшемуся, перечислю вознаграждение- Rothschild . Всем спасибо за помощь.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот