This is the way this DTS package evolved. I have recently learned that I can use a VBScript before each data pump gets executed to determine if it will execute the data pump or not. However this technique would cause the package to show all the data pumps as succeeded which I don't want.

If the way you are talking about to use global variables to avoid the dummy tasks works differently from what I described above I would love to hear more. I'd love to have the package execute without errors and without logging a success for the data pumps that don't actually pump data.

As Steve Jones mentioned this is one of the reasons I created the seperate table, to log the start and finish of each of the tasks. The other reason is that when I first started working with DTS packages I didn't know where to find the task name and so the error logs were meaningless to me.

I did not mean to imply that the way I solved the problem described in the case study was the best. It was the best I could do at the time I developed each task. As I learn new techniques I do my best to implement them, however I don't always have time to put them. Unless the DTS package actually stops working or needs to be changed I often don't have time to improve them.

None of what I said is meant as an excuse just as the reason why the DTS package is the way it is and thus this is the way it was described in the case study.

Robert W. Marda

SQL Programmer

bigdough.com

The world’s leading capital markets contact database and software platform.