Conditional Step within a DTS package

Question

Conditional Step within a DTS package

Hassie

SSCommitted

Points: 1641
More actions
November 8, 2005 at 2:42 am

#67926

I currently have one master DTS package which launches other DTS packages from it. This runs daily but I want one of the packages within it to run just between Tuesday and Saturday, ie not Sunday and Monday.
What is the best way to achieve this?

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Daniel Forrester-253836 Say Hey Kid Points: 666 More actions · Answer 1

If there are no dependencies between the packages then it would be easiest to remove the package that runs only between Tuesday and Saturday from the master package and schedule it as a seperate step within the SQL Job. Then you can create 2 jobs, one for Tuesday to Saturday and the other for the rest of the week.

If the packages are dependent then you can add vbscript task within the main package with the logic required to handle the days of the week and conditionally run the step.

Hassie SSCommitted Points: 1641 More actions · Answer 2

In an ideal world I would want the package to run as one job - it is easier to administer and check the steps are running in the correct order.

I will give the vbscript task route a go.

Thanks

fperkins Ten Centuries Points: 1029 More actions · Answer 3

http://www.sqldts.com/default.aspx?t=6&s=103&i=218&p=1&a=7

Depends on how your packages are designed but before we moved to only ActiveX tasks, I used the branching method of this example and branched to a no-op sql task (SELECT 1 = 1) to avoid running the "real" tasks in the package.

This site also has a Conditional run example that may do what you need.

Also look at the WorkFlow Properties, Options, Use Active X. You can code stuff there to tell the branch to skip execute unless the day is one you want to run on.

juliekenny SSCommitted Points: 1558 More actions · Answer 4

We use a dynamic properties tasks to disable the next step in the job - thus causing the rest of the package not to run. This seems to work quite well and allows the package to be independant - i.e. it does run but its first step may cause the other steps to be skipped.