Когда вы открываете / запускаете пакет, запускается событие OnInformation, которое говорит что-то вроде
Пакет пытается настроить из XML-файла "c: \ ssisdata \ so_56776576.dtsconfig".
Когда Visual Studio / SSDT открывает / запускает пакет, который говорит, что использует конфигурацию, но по причинам, не может получить их, вы должны увидеть сообщения типа
Предупреждение при загрузке so_56776576.dtsx: сбой импорта файла конфигурации: "c: \ ssisdata \ so_56776576.dtsconfig"
и
Предупреждение при загрузке so_56776576.dtsx: файл конфигурации "c: \ ssisdata \ so_56776576.dtsconfig" не найден. Проверьте каталог и имя файла.
и
Предупреждение при загрузке so_56776576.dtsx: не удалось загрузить хотя бы одну из записей конфигурации для пакета. Проверьте записи конфигурации для «Конфигурация 1» и предыдущих предупреждений, чтобы увидеть описания того, какая конфигурация не удалась.
Если кто-то вручную отредактировал файл конфигурации и сломал XML, вы увидите предупреждение, например
Невозможно загрузить файл конфигурации XML. Файл конфигурации XML может быть поврежден или недействителен
Важное замечание в отношении конфигурации - , если не удается найти конфигурацию, SSIS продолжит работу вместе со значениями времени проектирования . Вот почему так важно проверить предупреждения, генерируемые при запуске вашего пакета. Если вы работаете вручную, убедитесь, что вы указали /rep ew, чтобы вы сообщали об ошибках и предупреждениях.
Догадывается о первопричине
Пакет имеет уровень защиты EncryptSensitiveWithUserKey, что означает, что учетные данные AD создателя пакета используются для хеширования вещей, в которых может содержать конфиденциальную информацию. Я мог бы использовать аутентификацию AD в моей строке соединения и указать, что соединение должно быть доверенным, но весь этот блок все еще будет зашифрован для моей учетной записи Active Directory. Когда вы придете и попытаетесь сохранить пакет, он не сможет расшифровать конфиденциальные данные, поскольку вы не я.
Два способа обойти это - использовать общий ключ (EncryptSensitiveWithPassword / EncryptPackageWithPassword), с которым трудно работать, плюс он идет вразрез с духом секретности, поскольку каждый знает секрет. Другой подход, который вы определили, - DontSaveSensitive, и на этом я остановлюсь.
Проблема, которую необходимо преодолеть, заключается в том, что с DontSaveSensitive в том, что каждый раз, когда вы сохраняете, SSIS собирается уничтожать любые знания имени пользователя и пароля из мест, которые могут его удерживать - например, менеджер соединений. Стратегия 2005/2008 для защиты от этого заключалась в использовании конфигурации или явных переопределений во время выполнения для предоставления имени пользователя и пароля. Мой типичный подход состоял в том, чтобы использовать конфигурацию, основанную на таблице, а не XML, так как я лучше защищал конфиденциальные данные в таблице, чем занимался ACL в файловой системе. Другая проблема, с которой мы столкнулись с несколькими разработчиками и конфигурацией на основе файлов, заключалась в том, что либо каждый должен был настроить свои файловые системы одинаково (а мы разработчики - уникальные радужные снежинки, так что это маловероятно), либо мы должны использовать сетевой файл общего доступа, который хорош до кто-то добавляет свои собственные значения к нему и ломает его или удаляет ваши изменения или любые другие проблемы.