Scripting Patterns - SQL Server Integration Services Design Patterns - page 104

identical; functionality such as error handling, compiler directives, and core framework
functionality is common to both the Script task and the Script component.
Should I Use Script?
Before we get started exploring the design patterns for using scripting in SSIS, a funda-
mental question should be answered: “Should I be using the scripting tools at all?”
As much as I believe in using the script tools in SSIS to solve difficult problems,
there's one piece of advice I almost always dish out when talking or writing about this
topic: only use the Script task or Script component in situations where existing tools
can't easily address the problem you're trying to solve. Although you gain a great deal
in terms of flexibility, you also lose a few things—design-time validation, easy reusab-
ility, and a GUI settings editor, among others—when you deploy an instance of script
into your packages.
Now don't take any of this to mean that scripting is bad, or that it is reflective of
poor package design (after all, this is a chapter describing recommended practices for
using script!). Quite the opposite, in fact—I've found many situations where the only
tool that could satisfy the ETL requirement was a well-designed script instance. The
point is that the Script task and Script component are complex tools intended for use in
atypical situations. Native components are much simpler to use and maintain. In situ-
ations where one or more native elements of SSIS can easily dispatch any ETL issues,
don't complicate the issue by reinventing the wheel with a script.
The Script Editor
Though their purposes differ greatly, you can expect a similar experience in the script
editor for both the Script task and the Script component tools. Features of both tools in-
clude
• The ubiquitous code window
• Project Explorer
• Full .NET runtime
• Compiler