An Open Thank You to the Microsoft SQL Server Team

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714698

  • ThomasRushton

    SSC-Insane

    Points: 22591

    Hurrah!  Finally, a (partial) resolution to a problem that's been around for over 20 years...  Yes, a full error set would be nice, but I suspect that that would involve a serious overhaul of the error handling system.  But this is a good step forward.  Thanks, Steve, for bringing it to our attention.

    ...but did you say it's TF-dependent?  Why?  Why can't they just surface this extra information by default?  Is it because they're putting it out as a different error message ID?

    Thomas Rushton
    blog: https://thelonedba.wordpress.com

  • Mark Dalley

    SSCrazy

    Points: 2550

    This is great news. Better late than never!

    From the SQL Server 2019 white paper:

    So that it cannot break existing applications parsing message ID 8152, this new message ID 2628 is an opt-in replacement, which can be enabled with trace flag 460.

    MarkD

  • Jeff Mlakar

    SSCrazy

    Points: 2879

    Don't forget Dark Mode! 🙂

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714698

    ThomasRushton - Thursday, September 27, 2018 5:00 AM

    Hurrah!  Finally, a (partial) resolution to a problem that's been around for over 20 years...  Yes, a full error set would be nice, but I suspect that that would involve a serious overhaul of the error handling system.  But this is a good step forward.  Thanks, Steve, for bringing it to our attention.

    ...but did you say it's TF-dependent?  Why?  Why can't they just surface this extra information by default?  Is it because they're putting it out as a different error message ID?

    I think this is a CTP thing, but I hope this is the default. After all, it returns a new error number.

  • RenoChris

    SSC Veteran

    Points: 259

    This is a beautiful thing for debugging.  Should there be a concern however, about potentially leaking sensitive data via attacks that exploit the error messages?  Perhaps that is why they will make it off by default.

  • crmitchell

    SSCarpal Tunnel

    Points: 4361

    An excellent point there Chris. I would want this set on any development machine but probably not on production machines. This is the same issue as we get in choosing between debug and release builds for the code.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714698

    I wouldn't think data is the issue, as error trapping should handle this if you have concerned. You can look for the error and redact the message.

  • crmitchell

    SSCarpal Tunnel

    Points: 4361

    Steve Jones - SSC Editor - Friday, September 28, 2018 7:07 AM

    I wouldn't think data is the issue, as error trapping should handle this if you have concerned. You can look for the error and redact the message.

    You can, but a lot of legacy software (if not most of it) will display the full error message if its not explicitly caught and ensuring you have identified everywhere in the code this could happen may not be practical - at least in the short term and may not be an option at all for 3rd party software.

  • webrunner

    One Orange Chip

    Points: 29836

    Yes! This is a great addition by Microsoft.

    I've seen some people state some valid concerns about whether the more informative error message could inadvertently leak info. That's certainly something to check for from a security perspective. But that's the case with any system that reports errors.

    At least now it is up to the organizations to enable or disable the more detailed string truncation error depending on their needs. Before the error was a little maddening with no simple way to find out the offending column or data.

    - webrunner

    -------------------
    A SQL query walks into a bar and sees two tables. He walks up to them and says Can I join you?
    Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Viewing 10 posts - 1 through 10 (of 10 total)

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