Вывод сообщений SQL отображается как ошибки в службах SSIS

Таким образом, мой пакет SSIS регистрирует сообщения о выполнении запроса как ошибки всякий раз, когда выполнение запроса завершается сбоем. Так, например, мой запрос имеет 2 оператора печати, и по какой-то причине запрос не выполняется из-за какой-то ошибки. SSIS регистрирует все 2 оператора печати вместе с фактической ошибкой. Я не хочу, чтобы пакет SSIS регистрировал сообщения печати как ошибки. Мой пакет читает эту информацию об обработчике событий OnError. и источник журналов установлен в: System::ErrorDescription. Рассмотрим следующий запрос:

PRINT 'Trying to set string value to a datetime column.'
PRINT 'So i should get this error: Conversion failed when converting date and/or time from character string.'
UPDATE TempTable SET CreateDateTime = 'StringValue'

Ниже приведен вывод/сообщение из SQL Management Studio. Последняя строка является фактической ошибкой, а остальные строки — это операторы печати.

Trying to set string value to a datetime column.
So i should get this error: Conversion failed when converting date and/or time from character string.

**Msg 3930, Level 16, State 1, Procedure pr_TempTable, Line 3 Conversion failed when converting date and/or time from character string.**

Но все эти три строки из окна сообщений обрабатываются обработчиком событий OnError в SSIS как несколько ошибок, когда я пытаюсь выполнить задачу SQL и запустить этот запрос.


person Nanu    schedule 12.10.2015    source источник
comment
Да, больше информации, пожалуйста.   -  person billinkc    schedule 12.10.2015
comment
Это больше данных, но нам нужна информация. Как выглядит хранимая процедура? Что генерирует исключение? Как выглядит ваша обработка ошибок? Вы пометили это как ssis-2012 и ssis-2008, что это? Если 2012 год, вы используете пакетную или проектную модель развертывания?   -  person billinkc    schedule 12.10.2015
comment
Что вы имеете в виду, это вывод из SQL Management Studio. Что заставляет вас думать, что операторы печати регистрируются как ошибка, а это совсем другое?   -  person Tab Alleman    schedule 13.10.2015
comment
@TabAlleman. Под выводом я имел в виду информацию, которую вы видите в окне сообщений в SSMS после выполнения запроса или процедуры.   -  person Nanu    schedule 13.10.2015
comment
@billinkc - я, честно говоря, не думаю, что это имеет какое-либо отношение к версии SSIS, ни к использованию модели развертывания пакета или проекта, ни к тому, какое исключение получает хранимый процесс. Я обновлю вопрос с образцом запроса. Это связано с поведением обработчика событий OnError в операторах SSIS и PRINT, используемых в запросе.   -  person Nanu    schedule 13.10.2015
comment
Итак, еще раз я спрашиваю, что заставляет вас думать, что операторы печати регистрируются как ошибка? И я бы добавил к этому, какое вам дело до того, что вы видите в окне сообщения в SSMS?   -  person Tab Alleman    schedule 13.10.2015
comment
@TabAlleman - когда я запускаю пакет SSIS локально, в окне выполнения я вижу, что все сообщения печати, возвращаемые запросом, вместе с фактической ошибкой фиксируются как ошибки. Итак, взяв пример выше, во время выполнения пакета в окне Progress я вижу три ошибки (2 из них действительно являются операторами печати, а 1 - фактическая ошибка, обнаруженная запросом). Меня не волнует, когда я вижу в SSMS, но я отправляю группе ошибки, обнаруженные SSIS, по электронной почте. И я не хочу отправлять только ошибку, а не операторы печати.   -  person Nanu    schedule 13.10.2015
comment
Можете ли вы отредактировать свой вопрос и опубликовать код, который вы используете для отправки электронного письма?   -  person Tab Alleman    schedule 14.10.2015
comment
@TabAlleman — пакет регистрирует все ошибки в базе данных, а затем в отдельной задаче пакет читает их и отправляет электронное письмо для каждой из них. Конечно, я могу создать задачу сценария для отправки только одного электронного письма при наличии набора ошибок. Но мне очень интересно узнать первопричину, почему обработчик событий onError будет захватывать сообщения печати как ошибку всякий раз, когда запрос терпит неудачу.   -  person Nanu    schedule 14.10.2015
comment
Мне тоже любопытно, поэтому я пытаюсь заставить вас показать код, вызывающий такое поведение. Можете ли вы опубликовать код, который регистрирует ошибки в базе данных?   -  person Tab Alleman    schedule 14.10.2015
comment
Хотя это не объясняет почему, это показывает, что кто-то обнаружил ту же проблему. По-видимому, это стандартное поведение, и вам, очевидно, придется обойти его: sqlservercentral. com/Forums/Topic1354462-391-1.aspx   -  person Tab Alleman    schedule 14.10.2015
comment
@TabAlleman - Спасибо, что поделились этой ссылкой. Я также пришел к тому же выводу, что это стандартное поведение, и мне придется его обойти. Спасибо, что изучили это. Очень признателен. Вы можете опубликовать то же, что и ответ, поэтому я могу закрыть пост.   -  person Nanu    schedule 15.10.2015


Ответы (1)


Сначала я подозревал, что вы на самом деле "печатаете" свои утверждения с помощью RAISERROR, что является довольно распространенной практикой.

Однако в ходе дальнейших исследований я обнаружил, что для команд PRINT стандартное поведение заключается в том, что они включаются в сообщение об ошибке, отправляемое вызывающему приложению последующим оператором RAISERROR в том же сценарии.

Поэтому, если вы не используете RAISERROR в своем скрипте, ваши операторы PRINT не будут рассматриваться SSIS как ошибки. Но если вы используете RAISERROR, все операторы PRINT, которые произошли до RAISERROR, будут включены в сообщение об ошибке, которое возникнет.

Это странно и далеко не интуитивно понятно, но кажется, что это стандартное поведение, и похоже, что вам просто придется его обойти.

person Tab Alleman    schedule 15.10.2015