In ch 14, I executed the batch file, correcting the path to and name of the package. A window popped up asking me with what application I would like to open the DTSX file. I selected Execute Package Utility and immediately knew I had made the wrong choice. Of course the selected application popped up, with ParallelDemo.dtsx filled in, and I clicked Execute.

What application for processing the package was I supposed to select?

Upon clicking Execute, the package executed and completed the loop; all the ctlTaskQueue records were updated. All the loop iterations were executed with the same thread. I think that this is not what we wanted.

I closed the Execute Package Utility, and the command window displayed a new output line indicating a second thread has been spawned. With all the records in table ctlTaskQueue updated, there was now nothing to do in this new thread.

Accepting that Execute Package Utility was the wrong application to be executing, it seems that in order for each iteration of the package loop to be in a separate thread, the execution of ctl_UseTask - containing SELECT and UPDATE statements - must complete before the batch file iterates to the next thread spawn and begins execution of the next SELECT from ctlTaskQueue. It is not OBVIOUS that ctl_UseTask will be faster than a single iteration in the batch file loop, but I suppose that this could be the case.

I started with the batch file that came with the download. That was my problem. In the download file, the START statement does not contain the path and file name of the project to be repeatedly executed. That path and file name are actually on the next line, which you might not notice unless you maximize the window, which I didn't do. I mistakenly thought the START statement was wrapping around, putting the path & file on the next line. So my original batch file had a line that only contained the path to my paralleldemo.dtsx package, and Windows queried me for a application to handle it.

When I arranged for the START statement to also contain the package path & name, the Execute Package Utility stopped popping up.

Just because the batch is spawning new spreads does not mean a every thread is doing some actual work.

I added a field, ID, to table ctlTaskQueue for the purpose of containing some identifier of the package execution underway when Start and Complete fields were updated. Updating this with the System::StartTime was not effective as that date is only good to the nearest second. I added a SCRIPT TASK prior to the loop and the\at script set a new variable with a GUID value. I modified the UPDATE CTL TASK to update field ID to this variable value.

Results of a couple of batch file executions showed that first thread executed multiple iterations of its loop (1st, 2nd and 4th iterations in one case, 1st and 3rd iterations in another case.) Other iterations executed just one iteration each. Your results may vary. My AdventureWorks2014 db has 5 years of sales data.

The text doesn't go into the relation between the loop in the package and the loop in the batch file. The relation varies.