В ходе работы с числами в запросе получил следующую ошибку:
Поискал в интернете и ничего путного кроме "изучайте" запрос или данные которые он использует не нашел.
а ИС нашел уже что-то вроде решения , но причину никто не указал (или плохо искал).
Ковыряясь в запросе нашел причину причем очень простую: все дело в функции ВЫРАЗИТЬ ххх КАК ЧИСЛО(5, 2), так вот если ххх будет больше 5 разрядов то мы и получим данную ошибку что логично, нельзя же 100 000 выразить как 99 999. А вот с числами после запятой все просто - они просто округляются сколько бы их там не было.
Переполнение поля: Ошибка SQL
Поискал в интернете и ничего путного кроме "изучайте" запрос или данные которые он использует не нашел.
а ИС нашел уже что-то вроде решения , но причину никто не указал (или плохо искал).
Ковыряясь в запросе нашел причину причем очень простую: все дело в функции ВЫРАЗИТЬ ххх КАК ЧИСЛО(5, 2), так вот если ххх будет больше 5 разрядов то мы и получим данную ошибку что логично, нельзя же 100 000 выразить как 99 999. А вот с числами после запятой все просто - они просто округляются сколько бы их там не было.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Ошибка может иногда возникать в типовых в запросах, где идут вагоны ВЫРАЗИТЬ(ВЫРАЗИТЬ(ВЫРАЗИТЬ и присутствуют операции деления например. В таком случае в результате действия ВЫРАЗИТЬ может вылететь ноль в знаменатель, но вместо ошибки деления на ноль в этой ситуации получается вот это вот всё и непонятно с какого перепугу
(15)
может вылететь ноль в знаменатель
...что чисто математически даст в качестве результата бесконечность - то есть, овердофига, ни в какое поле не влезет.
вместо ошибки деления на ноль в этой ситуации получается вот это вот всё и непонятно с какого перепугу
Думаю, что это как раз понятно: текст запроса на языке 1С транслируется платформой в запрос на языке СУБД и передается ей для выполнения. Поэтому ошибка возникает на уровне СУБД, а не 1С, о чем система честно докладывает пользователю.
(16) По факту всё правильно, но по смыслу издевательство - придти к мысли что там проблемы с делением на ноль можно было бы сразу же, будь там адекватное описание ошибки - "Ув.пользователь, ошибка SQL при запросе, что может быть следствием того-то и того-то". Согласитесь, это несколько меняет скорость понимания проблемы, нежели разбор типового запроса среди десятков ВЫРАЗИТЬ и попытка понять в каком из них что-то не так?
(16) Приведу вариант решения проблемы в данном случае, если кто-то столкнется с подобным:
В данном случае при ошибке, удалив ВЫРАЗИТЬ в этом месте из запроса, получаем отсутствие деления на ноль и при этом корректный результат
Попытка
Выборка = Запрос.Выполнить().Выбрать();
Исключение
Запрос.Текст = СтрЗаменить(Запрос.Текст,
"ТОГДА ВЫРАЗИТЬ(ЕСТЬNULL(УпаковкиНоменклатуры.Числитель,1) / ЕСТЬNULL(УпаковкиНоменклатуры.Знаменатель,1) КАК Число(15,7))",
"ТОГДА (ЕСТЬNULL(УпаковкиНоменклатуры.Числитель,1) / ЕСТЬNULL(УпаковкиНоменклатуры.Знаменатель,1))");
Выборка = Запрос.Выполнить().Выбрать();
КонецПопытки;
ПоказатьВ данном случае при ошибке, удалив ВЫРАЗИТЬ в этом месте из запроса, получаем отсутствие деления на ноль и при этом корректный результат
Ошибка возникает, когда под Выразить(....) получается большое число, у которого при указанном преобразовании обрезаются старшие разряды целой части
Так
и в
Т.е. в последнем запросе из 890 получится 90 - 1с понимает, что это жутко не правильно и уходит в ступор
Так
будет такая ошибка в таком запросе
Запрос.Текст="ВЫБРАТЬ
| ВЫРАЗИТЬ(12345678901234567890.0000001 КАК ЧИСЛО(23, 10)) КАК А";и в
таком
Запрос.Текст="ВЫБРАТЬ
| ВЫРАЗИТЬ(890 КАК ЧИСЛО(2)) КАК А";Т.е. в последнем запросе из 890 получится 90 - 1с понимает, что это жутко не правильно и уходит в ступор
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот