Соединение SSIS не найдено в пакете

Ответ 1

Кажется, что ваш пакет ssis указывает на другое соединение, которое могло быть deleted или renamed Попробуйте открыть компоненты SSIS и укажите правильное соединение, которое есть в вашем диспетчере соединений.

Это происходит, когда мы копируем компоненты пакета SSIS для создания нового пакета или из-за переименования соединений или могут быть все еще компоненты, которые используют старое соединение, определенное в вашем файле конфигурации xml (в вашем случае попробуйте проверить задачу Execute SQL Task, которая throwing error). Если вы используете XML для настройки, попробуйте развернуть новую.

Ответ 2

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

При создании пакета SSIS 2012 в окне Solution Explorer вы увидите папку "Менеджеры подключения" на уровне проекта. Это похоже на наиболее логичное место для создания соединения и должно использоваться при создании соединения, которое может быть использовано любым пакетом в проекте. Он включен на уровне проекта, а не на уровне пакета.

При запуске моего пакета dtsx с использованием dtexec я получил те же ошибки, что и выше. Это связано с тем, что соединение не включено в пакет (только проект). Мое решение состояло в том, чтобы войти в конструктор пакетов, а затем в окне диспетчера подключений, щелкните правой кнопкой мыши соединение на уровне проекта (которое показано с помощью префикса "(проект)" и выберите "Преобразовать в подключение к пакету". Это будет встраивать соединение в фактический пакет dtsx. Это облегчило мою проблему.

Ответ 3

Это также происходит, когда вы используете новую концепцию "Общий диспетчер подключений SSIS 2012", в которой диспетчеры соединений не определены внутри вашего пакета, а проект Visual Studio и просто получают ссылку в пакете. Выполнение его через SQL Agent или DTEXEC дает то же сообщение об ошибке.

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

Ответ 4

Благодарим вас за публикацию этой проблемы.

Одно разрешение: откройте пакет в форме XML через проводник Windows, найдите GUID для диспетчера соединений, который не может быть найден. В моем случае это было поврежденное соединение EventHandler, которое было повреждено. Этот же диспетчер подключений использовался в потоке управления, но так или иначе не был поврежден, поэтому пользователь не был явно знаком с пользовательским интерфейсом. Поскольку XML указывал на диспетчер соединений обработчика событий, я открыл вкладку обработчика событий в пользовательском интерфейсе и сразу же отобразил замечательный RED X в источнике и целевых объектах, которые ссылались на поврежденный идентификатор диспетчера подключений. Я вернул его правильному менеджеру, восстановил pkg и сохранил. Хорошо пойти.

Ключом было открытие pkg в формате XML и определение GUID в коде, чтобы увидеть, где он был неудачен. Если бы мне не удалось найти в нем ссылку на нее, я собирался либо переименовать XML-соединение в другой известный GUID в XML, а затем зайти в пользовательский интерфейс и снова направить его или полностью удалить.

Удачи.

Ответ 5

В моем случае я узнал, что проблема была ранее настроенным поставщиком журналов, поскольку старое соединение больше не используется. Чтобы решить проблему, нажмите вкладку "Проводник пакетов", затем щелкните "Поставщики журналов" и удалите устаревшего поставщика журнала. Я надеюсь, что это помогает кому-то.

Ответ 6

Предыдущие замечания об удалении или удалении соединения абсолютно возможны. Но вы также можете получить эту ошибку при попытке вызвать пакет, который использует соединения на уровне проекта (вместо соединений уровня пакета).

Если вы используете соединения на уровне проекта и все еще хотите использовать dtexec, никогда не бойтесь, что есть способ. Я бы не рекомендовал преобразовывать их в соединения уровня пакета (при условии, что вы создали их как соединения на уровне проекта по уважительной причине).

Вам нужно будет развернуть свой проект SSIS. Для вашего сервера SSIS потребуется создать каталог (https://msdn.microsoft.com/en-us/library/gg471509.aspx). После того, как у вас есть каталог, в вашем проекте SSIS выберите Project-> Разверните и следуйте за мастером. Результатом будет файл *.ispac, созданный в вашей папке решения SSIS/bin/Development

Теперь для команды money вместо вызова вашего пакета с простым: dtexec.exe/f "package.dtsx"

вместо этого назовите его так: dtexec.exe/project "<...>/project.ispac"/package "<...>/package.dtsx"

Файл ispac имеет информацию о соединении на уровне проекта, которая необходима для выполнения вашего пакета, и вы должны быть установлены!

Ответ 7

То, что я сделал для решения этой проблемы, было простым. Мне пришлось переименовать мой SQL Server, чтобы он отвечал на тег (localhos). После этого я изменил все соединения в SSIS и перестроил решение... он сработал. надеюсь, что это поможет вам

Ответ 8

Пакет прекрасно работает в пятницу, заходите в TFS и отправляйтесь домой. Откройте его в понедельник, получив ошибки везде. "переменная диспетчера соединений $ project._connectionstring не найдена в коллекции переменных".

Я rtclick - редактируйте соединение и проверяйте подключение, не работает. ConnMnger находится в списке менеджеров соединений в решении. Когда открыт объект TARGET, подключенный к этому диспетчеру соединений, и нажмите MAPPINGS, появится всплывающая ошибка. Нет ссылки на переменные диспетчера соединений в любом месте сопоставления.

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

PROPERTY: ConnectionString Используйте параметр Exisgint: $ Project :: ConnMgrName_ConnectionString ИЛИ Создать новый параметр: следуйте настройкам

Как только этот диспетчер подключений параметризуется, все работает. Несмотря на то, что Conn Manger существовал на вкладке Conn Manger, Conn Mgr уже указан в обозревателе решений и не работал 2 дня назад.

Странно. Без разницы. Microsoft является Microsoft. SQL Server - это SQL Server. Выберите свой яд.

Надеюсь, это поможет другому человеку сэкономить время.

Ответ 9

У меня была та же проблема, и niether из вышеперечисленного переделал ее. Оказывается, была старая задача sql, которая была отключена в правом нижнем углу моего ssis, который мне действительно нужно искать. Как только я удалил все это было хорошо

Ответ 10

В моем случае одна из задач обработчика событий указывала на старое соединение, которое было удалено, удалив неиспользуемую задачу обработчика событий, устранила проблему. Я в конечном итоге открываю пакет в формате XML, чтобы понять, что проблема связана с задачей обработчика событий!

Ответ 11

В моем случае я мог бы решить это проще. Я открыл архив x.dtsConfig, и по неизвестной причине этот архив не был в стандартном формате, поэтому ssis не смог распознать конфигурации. К счастью, я ранее архивировал архив, поэтому мне просто пришлось скопировать его в исходную папку, и все снова работало.

Ответ 12

Я получил эту ошибку при попытке открыть проект SSDT 2010/SSIS 2012 в VS с SSDT 2013. Когда он открыл проект, он попросил перенести все пакеты. Когда я разрешил его продолжить, каждый пакет не удался с этой ошибкой и другими. Я обнаружил, что в обход преобразования и просто открывая каждый пакет по отдельности, пакет обновляется после открытия, и он преобразуется отлично и успешно запускается.

Ответ 13

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

РЕШЕНИЕ:

Моя среда: 64-битный клиент Oracle SQL Server 3245

1. Для include/embed Connection

   • открытый пакет
   • щелкните правой кнопкой мыши по соединению
   • выберите вариант "Преобразовать в проект"

2. для каталога SQLISIS/Job Schedule задайте конфигурацию, следуя шагам на картинке

   • Прямо на 'SQL JOB-> Шаг "или" SSIS Catalog--> Пакет → Выполнить "и выберите" Свойства "
   • Выберите вкладку Configuration--> Дополнительно
   • Проверено 32-битное время выполнения

Я попытался опубликовать подробную информацию поэтапно, но Qaru не позволяет это из-за репутации. Надеюсь, я позже обновил этот пост.

Ответ 14

Это решение работало для меня:

Перейдите в SQL Server Management Studio, щелкните правой кнопкой мыши на шаге неудачи и выберите "Свойства" → "Регистрация" → "Удалить поставщик журнала", а затем снова добавьте его

Ответ 15

Другой перестановкой, которая вызывает проблему в 2008R2, является настройка пакета. Я установил свойство, которое нужно сохранить/настроить из файла dtsconfig, а затем удалить связанное с ним соединение. Разрешение было простым, отредактировав конфигурацию и отменив выбор нежелательного объекта, а затем выберите соответствующее свойство для переименованного диспетчера соединений. Ошибка не повторялась после сохранения, закрытия и повторного открытия проекта. :-)

Ответ 16

Я решил, что эта проблема была поврежденным диспетчером соединений, идентифицируя конкретное соединение, которое было неудачным. Я работаю в SQL Server 2016, и я создал каталог SSISDB, и я развертываю там свои проекты.

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

Чтобы определить поврежденное соединение, я сделал следующее. В SSMS я открыл папку каталогов служб Integration Services, затем папку SSISDB, затем папку для моего решения и до тех пор, пока не нашел список пакетов для этого проекта.

Щелкнув правой кнопкой мыши по неудачному пакету, перейдя в отчеты> стандартные отчеты> все исполнения, выбрав последнее исполнение и просмотрев отчет "Все сообщения", я смог изолировать, какое соединение терпит неудачу. В моем случае диспетчер подключений к пункту назначения. Я просто удалил диспетчер соединений, а затем воссоздал новый диспетчер подключений с тем же именем.

Впоследствии я вошел в свой пакет, открыл поток данных, обнаружил, что некоторые из моих пунктов назначения были освещены с красным X. Я открыл пункт назначения, повторно выбрал правильное имя соединения, повторно выбрал целевую таблицу и проверил сопоставления по-прежнему были правильными. У меня было шесть пунктов назначения, и только три имели красный X, но я щелкнул их всеми и убедился, что они все еще правильно настроены.

Ответ 17

Обычно я обнаруживаю, что, когда SSIS, похоже, иррационально жалуется на явно хорошее соединение, это связано с тем, что я пытаюсь определить соединение напрямую, используя переменную пакета, а не через диспетчер подключений. Пример: сегодня у меня была задача веб-службы, в которой я сделал ошибку, непосредственно создав выражение, определяющее его свойство "Соединение" с точки зрения переменной пакета, содержащей URL-адрес веб-службы. Обратите внимание, однако, что соединение - это не то же самое, что ConnectionString! Поэтому, когда я смотрел на задание, он искал весь мир, как будто все было действительным, потому что оно отображало абсолютно правильный URL-адрес как "Соединение". Проблема в том, что Connection не может быть строкой; это должен быть диспетчер подключений.

Ответ 18

Значение соединения в задании кажется чувствительным к регистру.

Ответ 19

Для пакета, разработанного в Visual Studio 2015, я обнаружил, что должен указать значение для параметра (которое будет иметь место при развертывании или запуске на другом сервере), который устанавливает строку подключения диспетчера соединений вместо использования значения времени разработки. Это приведет к подавлению сообщения об ошибке. Я думаю, что это может быть ошибкой.

dtexec /project c:\mypath\ETL.ispac /package mypackage.dtsx /SET \Package.Variables[$Project::myParameterName];"myValueForTheParameter"

Я протестировал это без или без параметризации строки подключения, которая находится на уровне проекта. Результат был тот же: т.е. мне нужно установить значение параметра, даже если оно не используется.

Ответ 20

У меня такая же проблема.

Я использую диспетчеры соединений на уровне проекта, и мои пакеты работают правильно в SSDT, но когда я развернул их и выполнил через задание с агентом сервера sql, я получил ошибки "Соединение не найдено".

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

Ответ 21

Это случилось для меня: SSIS-пакет, не созданный мной, в какой-то момент начал неожиданно вести себя, как, например, указание, что Connection not found -error, и моей задачей было исправить это. Когда я посмотрел на Свойства шага задания в заданиях агента SQL, он показал, что используемые конфигурации не используются, и источники данных были точными, какими они должны быть. Но сообщение об ошибке указывает на что-то другое. Затем я открыл нужный файл .dtsx и заметил, что есть пакет IS conf. установить и в этом пакете конф. файл - это имя подключения, заданное неверно. Поэтому я советую сравнить .dtsx и .dtsConfig -files рядом друг с другом.