Hi -

OK so when I say step(s) you say batch(s) because that is how SQL executes it as batches. As far as the Single User Mode, I took your suggestion and changed it to RESTRICTED.

All that being said, since our own IIS server is creating the connections that don't allow the restore to happen, if it is in Multiple Batch mode, I tried turning off the offending App Pools via timer a minute before the SQL Job runs. Then 6 minutes later, the App Pools get turned back on. It is kind of clumsy because that job runs on a separate server inside Windows Tasks, but based on my limited knowledge of getting SQL Server A to talk to Web Server Z, that is the best I can come up with.

But what you are telling me about the execution of batches on SQL makes sense. Each batches timing is based on how long that server takes to run it. but if the batch is 'all inclusive' the timing is less, therefore the connections don't have as much time to re-establish themselves.

Since this is a production environment that I can't mimic it is hard for me to test all of this. But last night when the job ran at 1 AM I happened to be awake so I checked it. It ran successfully with the modifications I made. Gave a few errors of PIDS not being available to be killed, but that maybe because they were already killed and my Proc has them stored in a temp table to iterate through them, and when the execute of the KILL statement happens might have to be reviewed.

Thanks for the help.