Тупик при регистрации изменения значения переменной с помощью задачи SQL

Эврика!

У меня была такая же проблема и привела к нескольким тупиковым постам, потом обнаружил рут.

У меня была инфраструктура, работающая нормально, и я хотел принудительно зарегистрировать некоторую информацию. Поэтому я изменил значение переменной фреймворка «strVariableValue», и это вызвало тупик с задачей изменения события. Я исправил, создав свою собственную переменную «strLogMe» и поместив все, что хотел, в журнал.

Мораль: не трогайте переменные фреймворка

Вы использовали образец кода из книги? Все файлы доступны на веб-сайте Wiley бесплатно< /а>. Пример кода включает пакет служб SSIS, сценарии sql и код VB для сценария. Если это не работает для вас, дайте мне знать, так как один из членов моей команды нашел способ регистрации изменений переменных, который отличается от этой методологии.

Я внезапно получал эту ошибку («обнаружена взаимоблокировка» и т. д.), которая, казалось, совпадала с I.T. сделав патч Microsoft Windows на сервере. Были пакеты, которые использовали задачи сценариев с переменными только для чтения и/или чтения-записи в пользовательском интерфейсе служб SSIS. Несмотря на то, что это казалось проблемой окружающей среды (поскольку пакеты работали в течение нескольких месяцев, а затем внезапно перестали работать, хотя я не изменил никакого кода), я подумал, что ж (как я видел из различных сообщений в блогах за годы прошло), были случаи, когда компании выпускали патчи для серверов, а затем их пакеты SSIS ломались; и блоги, казалось, говорили: измените способ блокировки переменных, не ссылайтесь на них в пользовательском интерфейсе; вместо этого заблокируйте их явно в коде. Итак, я попробовал то же самое. Это не исправило.

Оказывается, какой-то человек удалил разрешения пользователя, под чьим именем запускаются пакеты, из группы AD; эти разрешения были необходимы, потому что он пытался скопировать файл из каталога, который требовал разрешений на чтение в каталоге. Эти пакеты обычно вызываются заданием агента SQL с использованием идентификатора прокси. Когда пакет запускался вручную из SSMS, он работал. Но когда он был запущен путем вызова задания агента SQL, он потерпел неудачу.

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