By Jen Stirrup

Is SQL Server Integration Services (SSIS) is a victim of its own success? For many developers, it is possible to ‘get by’ in SSIS – in other words, it is possible to pull and push data around, using the easy-to-use drag and drop components to create a package. Unfortunately, this does not mean that the package has been created well. As a developer, you’re probably looking for efficiencies and performance improvements.

If you want to get clever and efficient with SSIS, then this means that it’s necessary to understand how to work smarter with it, rather than work harder. It will also help you to understand what’s happening when SSIS doesn’t work the way that you’d expect it to work.

With respect to SQL Server 2012, there are some instances where the package environment doesn’t have all of the information required to configure the package or even the whole SSIS project. How do you know where to start, if the package isn’t taking the information that you expect it to take?

One blog which covers this issue has been written by Allan Mitchell (Twitter) SQL Server MVP and SQLBits Organiser in the UK. Essentially, it is worthwhile reading the Allan’s blog in detail, but the take-away nugget is that you must understand the precedence with which values are used in an SSIS package’s execution in order to be sure that the package is firing the values with the precedence that you expect.

Allan’s blog also suggests taking a look at the some of the stored procedures in SSISDB, and this is also worthwhile in order to get ‘under the hood’ with SSIS for more effective troubleshooting.

To summarise, reading the blog will help you to get more detail with SSIS’ underlying behaviour, thereby taking you from a ‘drag and drop’ developer to someone who has a deeper knowledge of SSIS behaviour.

Author Bio

Jen Stirrup
Copper Blue Consulting