June 20, 2013 at 10:58 pm
Hi All
I am building a SSIS project using the Project Deployment model of SSIS 2012. I am configuring package level logging using the SSIS log provider for SQL Server and using a project-level connection in the configuration. The project-level connection has a project.param of the connection string.
The log events are being correctly logged to SQL Server however the Progress information tab indicates two duplicate errors that the project-level connection used for the log provider cannot be found.
"Error: The connection "xxxx_SSIS_Logging" is not found. This error is thrown by Connections collection when the specific connection element is not found."
If I use a package-level connection in the SSIS log provider, the log events are correctly logged and there are no connection errors in the Progress information tab.
Is anyone else observing this behaviour with project-level connections in the SQL Server log provider?
Has anyone had failure to log events due to a project-level connection in the SQL Server log provider?
September 4, 2013 at 2:16 am
I have the same problem in SSIS 2012 (using SSIS log provider for SQL Server):
Scenario (1) - When enabling Logging using a PROJECT Connection I get the error:
Error: 0xC001000E at Package1: The connection "TestConnection" is not found. This error is thrown by Connections collection when the specific connection element is not found.
NOTE: Despite the error message above, events have been successfully logged to [sysssislog] table!
Scenario (2) - When enabling Logging using a PACKAGE Connection No Error is reported.
The same connection provider (Native OLE DB\SQL Server Native Client 11.0)
is used in both scenarios
Any ideas how to stop the error message? Has anyone found a solution to this?
September 4, 2013 at 6:47 am
This may be due to the log initializing before the reference to the project connection manager. I am not sure why else the project connection wouldn't work. It's definitely odd that you can pick it, but it errors during execution. As you said, you can still use a package connection to log child events in a parent-child architecture, but can see how this could be annoying.
I do have a question though, what is the desire to log to SQL server in the project deployment model? Logs of IS catalog executions are saved to SSISDB automatically, with a couple different levels of granularity available as settings. It seems unnecessary to also log to sysssislog, as both are database-level logs.
I use a package file connection manager for text logging in my master packages as a secondary log to the built-in logging with project deployment in the catalog.
September 5, 2013 at 2:43 am
Thanks for the post.
I noticed this behaviour during development prior to deploying to an IS server, when I was developing and debugging packages on a local machine via SSDT. Development has since moved on to negate the need for SQL Server Log Provider.
I know the IS Server Catalog logging is available and rely on that when the project and packages are deployed.
cheers
Paul
March 19, 2015 at 11:42 pm
Nick Doyle (9/4/2013)
This may be due to the log initializing before the reference to the project connection manager.
I just came across this issue during a conversion of some 2005 legacy packages to the project deployment model in 2012. At first I thought the errors in the execution results were because of the conversion and needed fixing. As noted in this post however, it does look like it's related to the log initializing before the project connection manager.
It only occurs on the very first package that spins up, i.e. subsequent child packages (not executed out of process) do not have the same error. But if you execute one of those same child packages directly it will incur the error. Also as noted, it is benign and merely annoying because the SSIS Logging does occur as expected. It also does not appear to have an effect on the ambiguous(ly gay) MaximumErrorCount so I think we're also good there.
As far as the inherent redundancy that occurs with SSISDB...no comment, ahem. 😉
October 13, 2018 at 9:47 am
Bruce Hendry - Thursday, March 19, 2015 11:42 PMNick Doyle (9/4/2013)
This may be due to the log initializing before the reference to the project connection manager.I just came across this issue during a conversion of some 2005 legacy packages to the project deployment model in 2012. At first I thought the errors in the execution results were because of the conversion and needed fixing. As noted in this post however, it does look like it's related to the log initializing before the project connection manager. It only occurs on the very first package that spins up, i.e. subsequent child packages (not executed out of process) do not have the same error. But if you execute one of those same child packages directly it will incur the error. Also as noted, it is benign and merely annoying because the SSIS Logging does occur as expected. It also does not appear to have an effect on the ambiguous(ly gay) MaximumErrorCount so I think we're also good there.As far as the inherent redundancy that occurs with SSISDB...no comment, ahem. 😉
Just for the docs: this "behaviour" still exists with VS2017 and SQL2016 --> If you use the "old" logging with project-model-connectionmanagers it will throw you 2 error messages that the connection is not found, but will still log.. i have no solution to prevent this errrors and ignore them
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply