Simple Method to Validate Data Read at the beginning of an SSIS Package

We’ve looked at using transactions in an SSIS package to ensure that, for instance, the read data step in your package doesn’t fail after you’ve deleted the data it’s set to replace.
This is a very effective and really useful method, and it’s exceedingly flexible.
If your project spans multiple servers, though, this will require changes to the DST service settings that you might not be able to make.
There’s a simpler way, though it doesn’t offer all of the protections of wrapping your package in a transaction. We’ll take a look at that, here.

Utilizing Transactions in SSIS to Rollback After a Failed Import

SSIS is used primarily to import data into a database, particularly from flat files, but also from other databases. The typical SSIS package for doing this task looks something like the picture at the left: backup the current data, delete the current data from the destination table, and then import the data from the source.
This is all good, and it works well. When it works. The problem is that if there’s a problem with reading the data from the source (say, the credentials for the source database changed), you’ve already blown away the current (production) data. The job fails, and the data remains missing.

Disabling ASR on a Windows Server

ASR stands for automatic server recovery. It's a service whereby the iLO features of a HP server will reboot it, should it detect that something has gone wrong with the operating system. Good idea, except when the detected failure isn't really a failure. Or you want to be able to troubleshoot the problem while it's occurring.
The most straightforward method for changing this setting is to boot the server into the BIOS setup (F9) screen, and browse to Server Availability –> ASR Status.
Sometimes, you’d like to make this change without downtime, however. It appears it’s possible. Unfortunately, it also appears that a reboot, at some point, still is necessary.