sonny@nellhead.pointyhats.com wrote:
> Tony, when I need to branch in a situation like this, I always use an
> ActiveX task. It looks at the value of whatever global parm you have
> set in the preceding task, and based on that value, disables the
> workflow in the path you do NOT want to take, leaving the workflow of
> the path you DO want to take, enabled.
>
> Of course it requires that you initially design the package with two
> enabled workflows (tasks) leading away from the ActiveX task.
>
> So in your task 1, set a global parm to a value indicating the
> situation with the log table. Then have an ActiveX task next that
> checks that value. The ActiveX task will have two workflows to two
> tasks, only one of which will be executed.
>
> sonny
>
>
> tturner6@hotmail.com wrote:
> > I have written many DTS packages to move data, I've never had to branch
> > in my workflow of tasks.
> >
> > I'm creating a package which has a log table. It runs four times a
> > day. It will check the log table, if the package has already run,
> > stop. If it hasn't run, go on with further processing.
> >
> > I've create three SQL Tasks
> >
> > Task 1 - check table. Initialize parameter.
> >
> > Task 2a - If Task 1 has not run, continue with process and query
> > additional table.
> >
> > Task 2b - If Task 1 has run, Update batch control table and stop.
> >
> > Is this a task that needs ActiveX Scripting or is there a way using
> > the SQL Statements to determine which task to go to next after Tasks 1?
> >
> > Thanks!
> >
> > Tony