SSIS Connection not found in package

Question

I\'m kind of new to SSIS programming, and I\'m having some problems deploying an SSIS package.

This package runs correctly on my PC, does everything it needs to do ..

Answer 1

The previous remarks about deleting or removing a connection are absolutely a possibility. But you can also get this error when you attempt to invoke a package that uses project level connections (instead of package level connections).

If you are using project level connections and still want to use dtexec, never fear there is a way. I would not recommend converting them to package level connections (assuming you created them as project level connections for a good reason).

You will need to deploy your SSIS project. Your SSIS server will need to have a catalog created (https://msdn.microsoft.com/en-us/library/gg471509.aspx). Once you have the catalog, in your SSIS project select Project->Deploy and follow the wizard. The result will be a *.ispac file generated in your SSIS solution folder/bin/Development

Now for the money command, instead of invoking your package with a simple: dtexec.exe /f "package.dtsx"

instead call it this way: dtexec.exe /project "<...>/project.ispac" /package "<...>/package.dtsx"

The ispac file has the project level connection info that is needed to execute your package and you should be set!

Answer 2

I received this error while attempting to open an SSDT 2010/SSIS 2012 project in VS with SSDT 2013. When it opened the project, it asked to migrate all the packages. When I allowed it to proceed, every package failed with this error and others. I found that bypassing the conversion and just opening each package individually, the package is upgraded upon opening, and it converted fine and successfully ran.

Answer 3

I'm a little late to the party, but I ran across this thread while experiencing the same errors and found a different resolution.

When creating an SSIS 2012 package, in the Solution Explorer window you will see the Connection Managers folder at the project level. This seems like the most logical place to create a connection, and should be used when creating a connection that can be used by any package in the project. It is included at the project level, and not the package level.

When running my dtsx package using dtexec, I received the same errors shown above. This is because the connection is not included in the package (just the project). My solution was to go into the package designer, and then in the Connection Manager window, right click the project level connection (which is shown using the "(project)" prefix) and choose "Convert to Package Connection". This will embed the connection in the actual dtsx package. This alleviated my problem.

Answer 4

I determined that this problem was a corrupt connection manager by identifying the specific connection that was failing. I'm working in SQL Server 2016 and I have created the SSISDB catalog and I am deploying my projects there.

Here's the short answer. Delete the connection manager and then re-create it with the same name. Make sure the packages using that connection are still wired up correctly and you should be good to go. If you're not sure how to do that, I've included the detailed procedure below.

To identify the corrupt connection, I did the following. In SSMS, I opened the Integration Services Catalogs folder, then the SSISDB folder, then the folder for my solution, and on down until I found my list of packages for that project.

By right clicking the package that failed, going to reports>standard reports>all executions, selecting the last execution, and viewing the "All Messages" report I was able to isolate which connection was failing. In my case, the connection manager to my destination. I simply deleted the connection manager and then recreated a new connection manager with the same name.

Subsequently, I went into my package, opened the data flow, found that some of my destinations had lit up with the red X. I opened the destination, re-selected the correct connection name, re-selected the target table, and checked the mappings were still correct. I had six destinations and only three had the red X but I clicked all of them and made sure they were still configured correctly.

Answer 5

This seems to also happen when you use the new SSIS 2012 "Shared Connection Manager" concept where the connection managers are not defined within your package but the Visual Studio project and just get referenced in the package. Executing it via SQL Agent or DTEXEC yields the same error message.

I haven't found a solution for that yet but would love to get some feedback if anybody experienced it before.

Answer 6

The connection value in the job seems to be case sensitive.