Пакет служб SSIS отлично работает в VSTS 2019, но не в SQL Server 2017 через агент SQL или DTEXEC.

Question

У меня есть очень простой пакет служб SSIS с одной задачей SQL.Он отлично работает в Visual Studio 2019, но не работает в SSMS или через DTEXEC на сервере.

У меня установлен пакет EncrptSensitiveWithPassword.Я разработал пакет локально, с моим пользователем на компьютере.

Для развертывания я скопировал DTSX на сервер и использовал учетную запись sysadmin для настройки задания агента sql для запуска его из файловой системы.

Когда мой целевой сервер пакета установлен правильно на 2017, я получаю:

Выполнено от имени пользователя: NT Service \ SQLSERVERAGENT.Microsoft (R) SQL Server Execute Package Utility Версия 13.0.4574.0 для 64-разрядной версии Copyright (C) 2016 Microsoft.Все права защищены.Начато: 8:54:27 AM Ошибка: 2019-06-27 08: 54: 27.23 Код: 0xC0010018 Источник: Package_v2
Описание: Ошибка при загрузке значения DTS: ConnectionManagers xmlns: DTS = "www.microsoft.com/ SqlServer / Dts "DTS: ConnectionManager DTS: refId =" Package.ConnectionManagers [Целевая БД] "DTS: CreationName =" OLEDB "DTS: DTSID =" {7DB8E823-90A7-499C-85AF-8304FACarge75} "DTS: ObjectNameЦелевая БД "DTS: ObjectD" из узла "DTS: ConnectionManagers" . Ошибка завершения Не удалось загрузить пакет "F: \ SSIS \ Импорт хранилища данных \ Package_v2.dtsx" из-за ошибки 0xC0010014. Описание: не удалось загрузить пакетиз-за ошибки 0xC0010014 "Произошла одна или несколько ошибок.Там должны быть более конкретные ошибки, предшествующие этой, которая объясняет детали ошибок.Это сообщение используется как возвращаемое значение из функций, которые сталкиваются с ошибками. ". Это происходит, когда происходит сбой CPackage :: LoadFromXML. Источник: Package_v2 Начало работы: 8:54:27 Окончание: 8:54:27 Истекшее время: 0,079 секунды.пакет не может быть загружен. Шаг не выполнен.

Изменение целевого SQL Server на 2016 или более раннюю (неправильное) дает мне тайм-аут соединения с базой данных. Переключение с 64 на 32-битное не имеет значения (оба моимашина и сервер в любом случае 64-битные).

Google был довольно бесполезен.

Answer 1

С выпуском в 2016 году инструментария SSDT / Visual Studio для проектов BI у нас есть возможность указать, какую версию пакетов служб SQL Server Integration Services должен создавать проект.По умолчанию задана последняя доступная версия SQL Server.

При развертывании на SSISDB никакие проверки не выполняются, чтобы проверить, что большой двоичный объект (ispac), который мы вставляем в базу данных, соответствует тому, что база данных может «говорить».Итак, вы создали проект с использованием версии 2019 инструментов обработки данных, которая предполагает, что вы развертываете на экземпляр сервера SQL Server 2019, но на самом деле развертываете до 2012 года, и веселье наступает, потому что API для развертывания тот же.

Как я могу сказать?

Откройте ваш проект служб SSIS, и если он выглядит так, он нацелен на то, что VS считает текущим.Это Visual Studio 2017, и мы думаем, что SQL Server 2017 - это то, на что мы нацелены.

Щелкните правой кнопкой мыши по проекту (в моем примере - SO_Trash)) и выберите Свойства

В этом окне разверните Свойства конфигурации, выберите раздел Общие, а там в Целевой версии развертывания измените значение TargetServerVersion с SQL Server 2017 на SQL Server 2016

После нажатия OK и подтверждения Visual Studio, что вы хотите перезагрузить свой проект, вы должны увидеть что-то вроде этого.

Имя моего проекта теперь указывает на целевую версию в скобках, таким образом SO_Trash (SQL Server 2016).

Со всеми вашимибиты проекта, соответствующие ожиданиям сервера, разверните и попробуйте запустить пакет (или нажмите кнопку «Проверить» в SSMS, но никто этого не делает)