Что-то меняется, если я в пакете PackageLoop у контейнера ставлю Propagate = False и MaxErrorCount = 0.
А также, если у пакета выше PackageFirst ставлю MaxErrorCount = 0. Но тогда я теряю в обще все ошибки, что тоже критично плохо.
Не говоря уже о том, что оч желательно решить проблему изменениями только внутри PackageLoop.

Попробую ещё раз описать картину (все имена и фамилии вымышлены):

1. Есть SQL job, который просто запускает etl пакет PackageFirst.dtsx.**
2. Пакет PackageFirst.dtsx просто запускает внутри себя другой пакет PackageLoop.dtsx.
3. Пакет PackageLoop.dtsx содержит в себе вызов третьего пакета PackageToDo.dtsx.
Но не простой вызов, а в цикле, т.к. пакет PackageToDo.dtsx первый раз может упасть (он обращается к сторонней системе и там то таймауты, то пожары, то ещё что-то), поэтому его повторно перезапускаем через 5 секунд.

Это всё работает, цикл шустро вращается, перезапускает пакет, всё круто.
Проблема в том, что если была одна неудачная попытка запуска PackageToDo.dtsx, то самый первый пакет PackageFirst.dtsx всё равно после отработки выдаёт ошибку из-за, как я понял, ворнинга* "всё хорошо, но внизу было больше одной ошибки, поэтому я всё равно считаю, что всё плохо". А в следствии после отработки выдаёт ошибку и SQL job и шлёт письма счастья с ошибками "пакет упал, что там не знаю, смотри сам", хотя по факту всё хорошо.
Пока единственный найденный вариант спасти джоб, это в пакете PackageFirst.dtsx поставить MaxErrorsCount = 0, но тогда идёт игнор в обще всех ошибок, что тоже не вариант.

Мне кажется, решения тут нет. Или я делаю что-то не так.

a_voronin, я оборачивал тело цикла в контейнер и ставил ему MaxErrorsCount = 0, ожидал чуда, но ничего не изменилось. На уровне пакета всё как работало гладко, так и работает. А пакет выше как выдавал ошибку, так и выдаёт.


*Полный текст ворнинга:
"Warning: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors."
** скриншот повторно приложил
*** прошу прощения, я кажется запутал вас, т.к. не разделил понятия "падает" и "выдаёт ошибку после отработки".

UPD:
Например только что вот нашёл
"Even when set propagate to false, errors raised in a child package are still passed to the parent package." etc
(c) https://bengribaudo.com/blog/2014/08/22/3291/understanding-maximumerrorcount
Похоже, от этого не уйти.

HandKot, за пределами Дании тоже какие то проблемы.)

Это ты показываешь лог непосредственно того пакета в котором цикл вращается.
Покажи, пожалуйста, лог родительского пакета, который вызывает этот пакет с циклом. (И у которого, естественно, MaxErrorsCount по дефолту везде равны единице.)
Т.е. прям уточню и отмечу - я говорю про пример с иерархией в три уровня; пакет с циклом это второй уровень, над ним ещё один изначальный пакет есть, с которого запускается вся эта бандура.

Если у тебя и родительский пакет не падает, тогда я снимаю шляпу и пробую разобраться как у тебя это получилось.)
Во вложении дублирую скриншот примера от меня.

HandKot, и т.е. в данном случае джоб, который запускает этот пакет не упадёт? и в логе не будет ворнинга о превышении количества ошибок?
У меня просто всё как было, так и осталось, как и писал в первом своём сообщении. Во вложении пример лога. Всё отрабатывает, но наверху пакет падает, если у самого пакета(!) на установить MaxErrorsCount = 0. Но тем самым отрубить в обще стандартную обработку ошибок, а это не ок (пробовали, упустили нюанс, неделю не знали об ошибке в дебрях почтового сервера).

Уже не говорю о том, что я упростил пример до иерархии в 3 уровня, на самом деле же уровней 5, и отключать так стандартную обработку ошибок и включать рукодельную обработку ошибок у каждого уровня это ад, т.к. тогда речь идёт о переделке не одного пакета, который одинаков в 10 проектах; а 100 пакетов в 10 проектах, которые не факт что везде одинаковы.

Т.е. было бы идеально только на уровне пакета с циклом отрубить всплывание инфы об ошибках того, что вращается в цикле. Но это, похоже, нереально, без переделки и добавления обработчиков ошибок во все верхнеуровневые пакеты.
Повторюсь, сейчас все верхнеровневые пакеты работают без проблем, но в конце каждый выдаёт ошибку, т.к. где-то внизу была одна неудачная попытка.

UPD: ок, дополню, да, ошибся, если добавить ещё propagate=false у компонента, то и этот пакет не падает.
Но если учесть, что этот пакет вызывается ещё одним пакетом выше, то и там надо делать тоже самое. =D
Ну вот такой у нас исторически обросший пятиуровневый проект. Всё работает на ура, если не учитывать нюанс, что эти чертовы ошибки не остановить, без обработки на каждом уровне.

PS: пока решили забить на это, раз похоже это невозможно без тотальной доработки всех пакетов (а это повлечет тотал тест, риски и тд) или мб в обще пересмотра концепции вселенной (не вариант), пока всё решается настройкой фильтра в мониторинге ошибок))

HandKotне стандартным шагом а через ScriptTask
О, огонь О_О , может сработать! Как я сам не додумался... Спасибо!
В следующую итерацию тыканья палочкой в эту задачу попробую!
Спасибо!!))