Hi,

Thanks a lot for the detailed reply. I totally take your point that a full restore (with DBCC CHECKDB) would be the only way to be absolutely sure that the backups are valid, and you are spot on with the reason why this is an issue here (disk space). I have nudged the powers at be a few times but nothing doing so I'm trying to implement a 'second best' solution, not ideal at all but better than nothing.

Thanks for pointing out the @@ERROR global variable. I've looked into this as I was not aware of it's use, etc. Doing that digging has led me to a similar approach using TRY and CATCH, and this seems to be working. So thanks for the lead 🙂 I'm inserting the value of @@ERROR into a table and will be using this in my routine.

I've noticed that the output from @@ERROR is an error code (3013) and not the count of errors as you mentioned. I'm using RESTORE VERIFYONLY within a loop. Does this seem OK to you? I believe @@ERROR is returning the last error code returned in the TRY BEGIN ....TRY END block.

I've checked out the article you linked to. That looks very useful.

Once again thanks for the reply.

Dave