Post reply

DBCC CHECKDB WITH TRY/CATCH

  • July 18, 2012 at 11:53 am

    #1514403

    Thanks - this is helpful and makes sense.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • July 18, 2012 at 11:45 pm

    #1514610

    Very nice question, thanks.

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • July 19, 2012 at 9:12 am

    #1514919

    Good question, wish my head was clear enough that I could have thought about it long enough to get it right. 🙂


    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • July 19, 2012 at 10:57 am

    #1515013

    Thank you for such interesting question.

    Best regards,

    Andre Guerreiro Neto

    Database Analyst
    http://www.softplan.com.br
    MCITPx1/MCTSx2/MCSE/MCSA

  • July 22, 2012 at 11:24 pm

    #1516067

    Nice question.

  • July 27, 2012 at 1:26 pm

    #1518724

    Nice straightforward question.

    The reference given is am SQL 2005 note, which does say it also applies to SQL 2008. There was a connect item on this which was closed "will not fix" but the MS comment at the time was "we won't fix this in SQL 2005".

    So it's not really clear what will happen with SQL 2012. At least not from any documentation provided by MS. Of course, MS won't fix it; their explanation of why it happens is probably correct but is such that if that really is the cause then it would be utterly trivial to fix it, but as they haven't bothered even to update BoL to state that it doesn't raise errors it seems obvious that they can't be bothered with it - they think it's not even important enough to document in BoL.

    Actually, to me it doesn't really matter; there's an easy workaround (just copy @@error immediately after the DBCC execution (thats the error code for the last error, if any, detected by DBCC) and then start a try block and raise an error if the copied value is nonzero. I think putting the DBCC call in the try block makes the error messages all disappear so you shouldn't do that.

    Tom

  • August 8, 2012 at 11:52 am

    #1523300

    Interesting question, thanks

  • October 22, 2012 at 11:08 pm

    #1551721

    +2. thanks:)

Viewing 8 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic. Login to reply