В OnPreExecute пакета находится Задача выражения1, в которой переменной, объявленной на уровне пакета, присваивается значение 1.
В самом пакете находится Задача выражения2, в которой этой же переменной присваивается значение 2.
И за ней следует Задача "Отправка почты", в которой значение переменной отправляется на почту.
В OnPreExecute Задачи "Отправка почты" вижу (в отладчике), что значение переменной = 2.
А в OnPostExecute Задачи "Отправка почты" оно опять становится = 1. Ну и на почту падает значение 1 (что еще более не понятно ведь было же оно 2 в OnPreExecute).

Пакет бессмысленный, сделан под вопрос.
Почему 1??? И если это штатное поведение, как на него повлиять?
Переменная в пакете одна, совсем одна, ну т.е. путаница на уровне пространств имен исключена.

В реальной задаче планируется по ходу выполнения пакета собирать (склеивать) данные в переменной в OnPostExecute на отдельных задачах и потом отправлять значение переменной на мыло. Но не тут-то было =(

.Евгений,

Изначально переменной присваивалось 2 прямо в OnPreExecute «Отправки почты», а в самом пакете задач не было вообще, кроме «Отправки почты». Ситуация была ровно такой же: 1 в OnPostExecute «Отправки почты» и 1 уходило на мыло.

Ну т.е. и у пакета, и у «Отправки почты» были свои обработчики OnPreExecute.

.Евгений,

Я пользуюсь этим, например, когда нужно, чтобы исключение, возникшее в задаче, не выталкивалось выше на уровень контейнера и/или пакета. И таким образом перехватываю/обрабатываю исключение в управляющем поток нужным мне образом.

А вот про то же самое в отношении обработчиков не сообразил. Спасибо, буду пробовать.

Единственное, что меня смущает, выше Вы говорите, что обработчик срабатывает и для «вложенных» объектов (спускается вниз). А в последнем примере наоборот: выталкивается вверх.

Перепроектировать? Можно обойтись и без использования обработчиков, наплодив кучу задач в самом потоке. Это затруднит визуальное восприятие основной бизнес-логики пакета. Потому сбор этой информации (по сути некое журналирование процесса) и хочется спрятать в обработчиках.

.Евгений,

Для прикладных целей штатный журнал не совсем подходит.
Скажем так, получатель сообщения должен видеть верхнеуровневую информацию, например, что пакет не смог завершиться успешно, потому не доступен ftp, куда он должен выложить файлы. И т.а.

А для отладки да, самое-то. В целом, в SSIS не было задач и проблем такой сложности, которые требовали включение и изучение журнала.
В общем, буду изучать. Спасибо!

.Евгений,

Так не очень нравится. Куда нагляднее в OnPostExecute отработавшего компонента (а точнее, в каждом нужном компоненте) сформировать нужный фрагмент текста и приклеить его к строке сообщения, которое в конце пакета и отправляется.
Ну представьте, я удалил компонент, а ещё лучше — переименовал его. Придётся править код в обработчике уровня пакета. Лениво =)

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/68bdfa69-50fa-4571-850f-1f1ad0ed4785/onpostexecute-should-run-only-once?forum=sqlintegrationservices

По мне так с «фиктивным» контейнером очень красиво

Ну не все так печально, конечно. Ниже лежащие можно запихать в контейнер и устанавливать Propagate=False в нужном обработчике контейнера, а не каждого компонента. Проверил, все очень хорошо работает теперь. Но да, появился "бессмысленный" контейнер. Все лучше, чем проделывать эти манипуляции с каждым компонентом в нем.


Тут не поспоришь. Но в принципе, этому кому-то еще достаточно понимать, что сборка итогового сообщения ведется только в обработчиках OnPostExecute, а в контейнерах выставляется Propagate=False. В любом случаем, мне кажется, это лучше, чем "засорять" основной поток дополнительными задачами, которые лепят сообщение.