However, whenever a task fails, the error gets reported up the Parent / Child package chain all the way to the SQL Agent Job running the control framework and the SQL Agent job itself reports failure. This gives the wrong impression to anyone viewing the job history – it looks like the job has failed when in fact it has run just fine, handling the problems it encountered.

Rushabh Mehta presents an elegant solution in this post: Gracefully Handing Task Error in SSIS Package. His solution is to create an OnError Event Handler for the task that can possibly fail, and in that Event Handler find the System Variable Propagate and set its value to False. What the Propagate property does is decide whether Error messages are propagated up through the package. By setting it to false, you tell the package not to send Error messages up the execution chain. The Event Handler itself doesn’t have to do anything, it just has to exist and have the Propagate property set to False. This way the task can fail, not cause the SQL Agent Job to fail, but still allow handling of Errors in the Control flow through the normal use of Precendence constraints.

Unfortunately if you have a chain of Parent – Child packages this doesn’t quite work. If you try to apply this technique to an Execute Package task, it doesn’t work because if the Child package fails at any point – even if you prevent errors propagating up from inside the Child package, the Parent package will still raise errors and report failure. What I have found is that you have to have an Event Handler that prevents the propagation of errors at each step in the chain of packages that call that child package – so if you have Parent > Parent > Parent > Child, stopping propagation of errors in the Child isn’t enough to get the SQL Agent Job to believe it succeeded, you need to stop error propagation at each Execute Package task. I have a set of sample packages demonstrating this process here. It appears the only way to ignore errors at the bottom level is to ignore errors at every level, which is not a good approach.

As far as I can tell this is a bug, so I have reported it on connect.

If anyone has a solution to this problem I would be grateful to hear it – I don’t want to disable errors in every called package, just stop them propagating from the Execute Package Task at the bottom of the chain.

Connect Update 18 Aug 2010: 

Looks like this won’t get fixed as it currently stands, the response from Microsoft was to Close it as “By Design”:

The “propagate” value only controls if an event should be propagated up
repeatedly. It doesn’t affect if the event is propagated to the client.
For child task, client is the parent package.

We looked the issue and decided that we cannot change the current
behavior. To address the issue properly, we will consider introducing
option like “Propagate to client” in the future.

 This does actually make sense architecturally – so we will just have to hope that the “Propagate to client” property becomes a reality.

It is possible to pass a value from SQL Agent into a variable in SSIS. You need to predefine the variable within the package – assume it’s called strAgentInput in the Control namespace.

In the SQL Agent step that is calling the package, you’ll note a tab in the options called “Set Values“. To pass a value into a variable, enter in the Property Path column (including the leading backslash):

\Package.Variables[Control::strAgentInput].Value

Vary the namespace and variable name as per your package needs. You can also see the .Value property of the variable is being set here – you can set any other variable property here – but you must set a property. If you do not specify which property you are setting, nothing will get set.

To set the actual value, enter what you need in the Value column. What gave me so much trouble was entering a file path. The correct syntax for file paths is:

“C:\Program Files\Microsoft SQL Server\90\DTS\Packages\\”

Note the string is surrounded by double quotes and the final slash of the path is escaped by a backslash. Any other variation will lead to your string output having “/REPORTING E” tagged on the end of it. Which drove me insane trying to figure out. Hopefully i’ve saved you some pain.