Очень прошу помощи. При расчете бух итогов в ПУБ стала выходить ошибка State: 22003 Native: 8115 Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric. У нас сервер sql 2005. Не понимаю в чем причина. После этого сообщения программа слетает. Пытаюсь опять зайти в 1С и опять начинается пересчет итогов. Кто сталкивался с такой ошибкой, просьба помочь
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Подобная ошибка может возникать, если на SQL2005 не "натянуты" сервиспаки, но может и по другим причинам. Если размеры базы позволяют, то можно выгрузить базу в локальную, провести расчет итогов и загрузить ее обратно - как вариант.
Нет. В копии базы восстановление проходит, но копия 10 дневной давности. А в самой базе исправления не проходят. Получается, что бух итоги на 31.12.11 - 100 рублей, а 1.01.12 остается только 1 руб
Не написала сразу. Проблему решила путем написания программы по очистке базы в регистрах и бух итогах очень больших итоговых чисел. Сейчас все работает. Спасибо всем, кто пытался мне помочь
(9), (10) обработка это конечно здорово, но для начала надо смотреть, откуда ноги выросли. Это же банальная ошибка переполнения. Возникает не по техническим причинам, а потому что итоги не закрываются, или обороты вылазят из разрядности.
(11) ADirks, а можно поподробнее? У меня есть большой запрос с анализом данных много откуда. Допустим для того чтобы узнать какой регистр накопления дает ошибку мне нужно сделать по нему запрос с оборотами за период итогами и остатками и итогами так? И тогда данная ошибка вылезет?. Пока решил проблему увеличением длинны ресурсов регистров с 10 до 15 символов.
(13) Как оно вылезет в запросе я не знаю. Итоги в запросе считаются локально, и вполне вероятно, что 1С разрядность таки увеличит.
Разрядность ресурсов можно смело увеличивать до максимума - на размеры БД это никак не влияет, ибо
numeric (p, s) Fixed-precision and scale-numeric data from –10^38+1 through 10^38–1. The p variable specifies precision and can vary between 1 and 38. The s variable specifies scale and can vary between 0 and p. Storage size is 19 bytes.
10 - это маловато, любая конторка чуть покрупнее ларька, быстро вылезет за эти пределы. ну и нужно помнить, что первая цифра - это разрядность всего числа, вместе с дробной частью. т.е. Число(10, 2) - это максимум 10^7 (именно в седьмой, 1С трансформирует это в Numeric(9, 2))
Ошибка переполнения, как у автора, возникает в момент пересчета итогов - в данном случае бухгалтерских. В принципе тоже можно поставить везде разрядность 19, может и поможет.
Разрядность ресурсов можно смело увеличивать до максимума - на размеры БД это никак не влияет, ибо
numeric (p, s) Fixed-precision and scale-numeric data from –10^38+1 through 10^38–1. The p variable specifies precision and can vary between 1 and 38. The s variable specifies scale and can vary between 0 and p. Storage size is 19 bytes.
10 - это маловато, любая конторка чуть покрупнее ларька, быстро вылезет за эти пределы. ну и нужно помнить, что первая цифра - это разрядность всего числа, вместе с дробной частью. т.е. Число(10, 2) - это максимум 10^7 (именно в седьмой, 1С трансформирует это в Numeric(9, 2))
Ошибка переполнения, как у автора, возникает в момент пересчета итогов - в данном случае бухгалтерских. В принципе тоже можно поставить везде разрядность 19, может и поможет.
(16) ADirks, увы проблема не решилась даже увеличением длинны до 20 символов. Что сделал: Пересчитал итоги через Операции-Управление итогами, потом увеличил длинну до 15 и все заработало, откатился назад и начал постепенно у каждого регистра увеличивать длинну до 15, не сработало, увеличил длинну до 20 у всех и тоже не сработало. Что делать?
(13) rom-x, в каких именно таблицах нужно увеличить разрядность? тоже возникла такая проблема, думала на файловом варианте рассчитаю и загружу обратно, а sql при загрузке начинает пересчет итогов и опять падает с ошибкой арифметического переполнения.
Это же банальная ошибка переполнения.
Возникает не по техническим причинам, а потому что итоги не закрываются.
Возникает не по техническим причинам, а потому что итоги не закрываются.
У меня тоже обороты вылезли из разрядности. Обработка подделанная под наши нужды (когда-то ее нашла в инете, а потом пригодилась), но пока я не в своем городе, в отпуске, вышлю позже.
Ну так смотреть, что за обороты такие бешеные. Или остатки не закрываются.
Я же говорил, что обычно это не в данных косяк, а в алгоритмах.
Я же говорил, что обычно это не в данных косяк, а в алгоритмах.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот