Как игнорировать ошибки, связанные с арифметическим переполнением, в представлении данных?
У меня есть сложное представление данных, которое рекурсивно связывает и суммирует информацию.
Каждую ночь запланированная задача запускает хранимую процедуру, которая выбирает все данные из представления данных и вставляет их в таблицу, чтобы пользователи могли запрашивать и анализировать данные намного быстрее, чем выполнение оператора select в представлении данных. .
Родительская таблица состоит из нескольких сотен тысяч записей, а размер набора результатов экспорта превышает 1 000 000 записей.
В большинстве ночей процесс экспорта работает без каких-либо проблем, однако, если пользователь вводит неверное значение в нашей основной ERP-системе, это приведет к сбою ночного процесса, поскольку одно из десятичных полей будет содержать неподходящее значение. в некоторых преобразованиях, которые я должен сделать с данными. Отладка и поиск определенного ошибочного поля может быть очень сложной и трудоемкой задачей.
С учетом сказанного я прочитал о двух параметрах SQL NUMERIC_ROUNDABORTи ARITHABORT. Это звучит как идеальные варианты для решения моей проблемы, однако я не могу заставить их работать ни с моим представлением данных, ни с хранимой процедурой.
Моя хранимая процедура представляет собой не что иное, как оператор TRUNCATE и INSERT. Я добавил...
SET NUMERIC_ROUNDABORT OFF
SET ARITHABORT OFF
... к началу SP и это не помогло. Я предполагаю, что это связано с тем, что технически ошибка возникает из-за кода, связанного с представлением данных.
Затем я попытался добавить два дополнительных свойства в представление данных, надеясь, что это сработает. Это не так.
Можно ли настроить эти свойства SQL так, чтобы ошибки округления игнорировались, чтобы можно было экспортировать данные из представления данных?
Я знаю, что большинство из нас, отвечая на вопросы SO, первым делом хотят запросить код. Однако в этом случае код чрезвычайно сложен и проприетарен. Я знаю, что исправление определений, вызывающих случайное переполнение, является наиболее идеальным решением, но в этом случае гораздо эффективнее просто игнорировать ошибки такого типа, потому что они случаются очень редко и их так сложно устранить.
Что я могу сделать, чтобы игнорировать это поведение?
ОБНОВЛЕНИЕ
Я полагаю, что случайно нашел основную причину проблемы, однако понятия не имею, почему это могло произойти. Это просто не работает с тех пор.
В табличном представлении у меня есть различные вычисляемые поля. Поскольку эти поля должны соответствовать полям в таблице, которые определены как decimal (12, 5), я всегда оборачиваю операторы поля представления в CAST( ... AS DECIMAL(12, 5))статьи.
Случайно я наткнулся на диковинку. Я решил посмотреть, как SSMS «увидела» мое представление данных. В обозревателе объектов SSMS я развернул раздел Views->[My View]-Columns и увидел, что одно из полей определено как decimal (13, 5).
Я предположил, что, должно быть, допустил ошибку в одном из своих операторов приведения, но после поиска по всему коду табличного представления не нашел определения для поля decimal(13, 5)?! Мое единственное предположение состоит в том, что определение поля представления, которое видит SSMS, должно быть получено из результирующих данных. Тем не мение,Я понятия не имею, как это могло произойти, так как я каждое поле в decimal(12, 5).
Я хотел бы знать, почему это происходит, но, опять же, мой первоначальный вопрос остается в силе. Как и какой оператор SET я могу определить в представлении таблицы, который будет игнорировать все арифметические переполнения и записывать нулевое значение в поля с ошибочными данными?
ЗАКЛЮЧИТЕЛЬНЫЕ КОММЕНТАРИИ
Я отметил ответ HeavenCore как ответ, потому что он отвечает на мой вопрос, но не решает мою основную проблему.
После небольшого устранения неполадок и попыток заставить мой экспорт работать, мне придется попробовать другой подход. Я по-прежнему не могу заставить экспорт работать, даже если я установил для свойств NUMERIC_ROUNDABORTи ARITHABORTзначение OFF.