Step objects coordinate the flow of control and execution of tasks in a DTS package. A task that does not have an associated step object is never executed. Step objects provide “workflow” capabilities to the package so that tasks are executed in a certain sequence. For example, a database must be successfully created (Step A) before a table can be created within that database (Step B). This is an example of a finish-start relationship between Step A and Step B. Step B has a precedence constraint on Step A. Each step is executed when all of its precedence constraints have been satisfied. If a step does not define any precedence constraints, it is eligible for execution immediately. Tasks can be reused by subsequent steps, but can only be used by one step at a time.
Steps can be executed conditionally based on run-time conditions, and multiple steps can be executed in parallel to improve performance. For example, a package can simultaneously load data from Oracle and DB2 into separate tables in Microsoft® SQL Server™.
Because some operations are more time critical than others, the step object can also control the priority of a task. The PackagePriorityClassStep property controls the Microsoft Win32® process priority of the entire DTS package (idle, normal, or high). By default, each thread within the package runs at the same priority as the package process. The RelativePriority step property determines the relative priorities of the Win32 thread running the task and the package process.
Applications using the DTS API explicitly define steps using the Step object. Steps are not explicitly defined in DTS Designer. Users of DTS Designer specify workflows between tasks or connections. DTS Designer internally implements any step objects needed to support the workflow operations specified by the user.
Steps contain precedence constraints, which define the conditions that must be met by prior steps before the current step executes. Precedence constraints are used to control the flow of execution in a package at run-time using the return code of a previous step or a Microsoft ActiveX® script. This allows the implementation of simple IF-THEN-ELSE logic in packages.
A step can specify three types of precedence constraints:
The step executes when the prior step completes, regardless of the success or failure of the previous step.
The step executes when the prior step completes successfully. The step does not execute if the prior step fails.
The step executes when the prior step fails. The step does not execute if the prior step completes successfully.
A step can have multiple precedence constraints, it does not execute until all of the precedence constraints have been satisfied.
If you only want a step to wait until another step has successfully completed, use the Success constraint in your workflow. If you want to attempt an action, but require that the next step wait until the previous step has completed regardless of the outcome, use the Completion constraint. Use the Failure constraint when you want to run an alternative branch of the workflow when an error is encountered. For example, you might use Failure to send e-mail notifying someone that an error has occurred.
Steps A, B, and C do not have any precedence constraints defined and so are executed immediately in parallel by default. Step D cannot be started until Step A has completed successfully because it has a precedence constraint requiring the successful execution of Step A. Similarly, Step E starts after Step D has completed successfully, and Step F when Step C has successfully completed. Alternatively, Step D could have multiple precedence constraints requiring that steps A, B, and C all complete successfully before it is executed.
In another example, Step 1 loads a table from a text file. If the table is loaded successfully, then an index is created on the table (Step 2). If the table is not loaded successfully, then any rows that may have been loaded from the text file are deleted (Step 3). This is implemented using precedence constraints: