Database Reference
In-Depth Information
Figure 7-35.
Executing the entire SSIS package
We recommend that you test individual SSIS tasks as you go so that any error can be resolved sooner rather
than later. This approach is not always practical, however, when certain tasks are contingent on others running
or when the database must be in a certain state before your SSIS code executes, such as having the foreign keys
dropped before table data can be truncated. In cases like these, you need to pay close attention to the logical
order of your ETL tasks and create a strategy that is appropriate to what you are trying to accomplish.
Be sure to test the tasks both singularly and collectively whenever possible, and you will resolve many issues
that developers have when creating, deploying, and executing SSIS packages.
■
we recommend that you run the entire package twice. This is because your testing process may have
inadvertently set the state of your database objects to something other than normal. For example, some tables may
be filled, but others may not be. since most packages eventually are set up by a sQL administrator to run automati-
cally at night, nobody wants to find out that a package scheduled to run at 2 a.m. has failed. Running the package
successfully the first time may give you a false positive, while running it a second time will be similar to how it was
scheduled.
Note
