The Scripting Tasks

The Script Task is very important because it provides flexibility, quick extensibility, and a compromise option for gaps in functionality left between stock tasks and custom tasks. Scripting tasks provide a way to implement a custom task without the effort and discipline of building a full-fledged component. The Script Task takes care of the details so that you can concentrate on writing only the necessary code to accomplish the work at hand.

Former DTS users know that the Script Task in DTS was used frequently, in almost every package and was often employed to implement loops and configure the package. This is not the case in Integration Services. Most work you need to do in a workflow can be accomplished using IS features, such as configurations, deployment, property expressions, and stock tasks, or through a combination of those features. So, the Script Task is now generally used to implement what are essentially package-bound custom tasks.

This chapter covers the stock tasks, so we've included a Script Task entry for completeness and consistency; however, the Script Task is quite complex and too important to attempt coverage here. For detailed coverage of the Script Task, see Chapter 15, "Using the Script Task."

The ActiveX Script Task

The ActiveX Script Task remains essentially the same as it existed in DTS. It has been provided as a backward-compatibility option but should under very few circumstances be used for new development because it will be deprecated in the very near future. Script running in this task is interpreted and, therefore, much slower than comparable code running in the new Script Task. When the Migration Wizard attempts to migrate DTS packages that contain ActiveX Script Tasks, it creates an ActiveX Script Task as a target where it can store the script from the task in the DTS package. This should not be considered an encouragement to use it, however. You should eliminate the ActiveX Task from your migrated packages as soon as possible.