September 26, 2018 at 8:41 pm
Comments posted to this topic are about the item An Open Thank You to the Microsoft SQL Server Team
September 27, 2018 at 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?
Thomas Rushton
blog: https://thelonedba.wordpress.com
September 27, 2018 at 8:07 am
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
September 27, 2018 at 10:03 am
Don't forget Dark Mode! 🙂
September 27, 2018 at 11:13 am
ThomasRushton - Thursday, September 27, 2018 5:00 AMHurrah! 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.
September 27, 2018 at 11:28 am
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.
September 28, 2018 at 2:49 am
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.
September 28, 2018 at 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.
September 28, 2018 at 7:23 am
Steve Jones - SSC Editor - Friday, September 28, 2018 7:07 AMI 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.
October 2, 2018 at 9:04 am
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 asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply