Paul Randal (9/28/2012)
It's nothing to do with DBCC - it's the try/catch eating the errors being printed. No idea how to use that correctly - it has some weird behavior.Nothing changes the behavior of DBCC, but you're changing the way the DBCC output is consumed.
All I said was after running DBCC, the value of @@error will be non-zero if errors were found.
Paul,
OK, I confirm what you say about @@error after 'dbcc checkdb'.
So now I can catch all 3 situations:
dbcc checkdb
backup database with checksum
restore verifyonly with checksum
and if something goes wrong I get an email - heaven forbid.:w00t:
One thing that still leaves me a bit puzzled is that sometimes modifying a single byte somewhere in the database (MDF file) checkdb does not detect the database to be 'corrupt' (nor does backup with checksum). Maybe it's because the page is 'inactive', so I do a shrinkfile but I can still get this phenomena to occur. If every page (8192 bytes) in the file has a checksum then modifying a single byte at random should corrupt the database. I can only assume that not all pages get checked because they are 'not important' in some deep down technical sense.
Regarding 'restore verifyonly', there seems to be no difference between having 'with checksum' and not having it. I can corrupt a backup and I get the same error message with 'with checksum' and without it. But I'm happy doing it with 'with checksum'.
I will now stop corrupting things...:-)