Shifty Henry said to Bugs
You know those moments when you’re looking at something for so long, and it’s still not working, and you’re pretty sure you’re losing that final grip on your sanity?
Well, that feeling was multiplied this week by an odd bug that I found, where Query Plan Hashes in system views had leading zeroes after the 0x that were stripped out in the plan XML.
This is just a quick blog post to get some attention to the issue.
The Connect Item is here.
The GitHub issue with more information is here.
If any of you bold and brave people feel like upvoting, or checking their system for similar issues, thanks in advance.
And thanks for reading!
6 Comments. Leave new
voted
Thanks, appreciate it.
It seems like binary constants are not a standard thing in SQL. The ansi SQL standard doesn’t speak about them and Oracle uses something like 0b1234 instead of 0x1234. (So Microsoft may choose to do whatever they want)
The docs on binary constants https://msdn.microsoft.com/en-us/library/ms179899.aspx don’t mention behavior for an odd number of hexadecimal digits after the leading 0x.
When interpreting strings, SQL Server seems to forgive one missing extra zero when a literal binary string has an odd number of digits:
select ‘same’ where 0x01 = 0x1
— returns ‘same’, SQL Server automatically pads one extra leading zero for binary strings with an odd number of digits
select 0x1 + 0x1
— returns 0x0101
It seems like they’re hoping for the same sort of tolerance by apps that consume their reported handles.
It’s not just limited to one missing zero though. It happens with all leading zeroes (up to three I’ve noticed so far) that are discarded after the 0x. If it were just one I’d be thrilled.
Wow, that makes all the difference doesn’t it? That’s terrible. (upvoted)
Thanks!