November 17, 2010 at 3:45 am
mister.magoo (11/16/2010)
Thanks to those of you who appreciate this question.To those who think it had unnecessary "tricks" in it, I did try several variants of this question and they all ended up being too easy.
The "tricks" were deliberate and designed to check whether you would notice the implicit conversion and whether you even knew it would happen.
If you don't like the question, I am sorry - for those that like to be challenged to check every small detail I think it provides a sufficient level of complexity to give you a good challenge!
Have a nice day!
I got this one right because I'm always looking for a trick. That's a general problem with the QOTD. Too many of the questions have some trick in it so when there is a straight-forward question without a trick, I find myself looking for one anyway.
November 17, 2010 at 7:41 am
I learned a lot from this QOTD. Count me as someone else who didn't know there was such a thing as conditional order by.
I can see the utility of this and I can see that an implicit cast could cause problems, even an error-less unintentional sort as Tony++ mentions.
Thanks to depak.a for providing a solution to the implicit cast problem.
The swapping of string1/string2 was probably an unnecessary distraction but debugging with "distractions" is a part of life. I readily grant license to QOTD authors to add tricks if they prefer that type of question.
November 17, 2010 at 5:14 pm
Excellent question.
November 18, 2010 at 1:37 am
Hugo Kornelis (11/17/2010)Without the reversal, the question would have been a solid test of whether people know about the dangers of using CASE in ORDER BY, and thus an excellent question. With the reversal, it's still a good question - good, not excellent.
The QoTD was not about dangers of using CASE in ORDER BY, but the problem is in the convertion in the CASE clause.
November 18, 2010 at 2:06 am
Richard Warr (11/16/2010)
I thought it was an interesting question as well - currently more people have it wrong than right which shows that we can still be surprised at the "behind the scenes" antics of SQL Server.Please don't describe questions as "nonsense", people take taime to set them and always have good intentions when they do so. It doesn't help your case if you can't spell "nonsense" either.
I agree with you Richard! I admire the people who dare to post questions on this site.
/Håkan Winther
MCITP:Database Developer 2008
MCTS: SQL Server 2008, Implementation and Maintenance
MCSE: Data Platform
November 18, 2010 at 2:10 am
Carlo Romagnano (11/18/2010)
Hugo Kornelis (11/17/2010)Without the reversal, the question would have been a solid test of whether people know about the dangers of using CASE in ORDER BY, and thus an excellent question. With the reversal, it's still a good question - good, not excellent.
The QoTD was not about dangers of using CASE in ORDER BY, but the problem is in the convertion in the CASE clause.
Hi Carlo,
The implicit converts in the CASE are the root cause of the danger I referred to. And while the same thing may happen in a CASE anywhere, I have thus far only seen this in ORDER BY clauses. So I guess that you and I are saying the same thing, jusst using different words to describe it.
November 18, 2010 at 2:30 am
Hugo Kornelis (11/18/2010)
Carlo Romagnano (11/18/2010)
Hugo Kornelis (11/17/2010)Without the reversal, the question would have been a solid test of whether people know about the dangers of using CASE in ORDER BY, and thus an excellent question. With the reversal, it's still a good question - good, not excellent.
The QoTD was not about dangers of using CASE in ORDER BY, but the problem is in the convertion in the CASE clause.
Hi Carlo,
The implicit converts in the CASE are the root cause of the danger I referred to. And while the same thing may happen in a CASE anywhere, I have thus far only seen this in ORDER BY clauses. So I guess that you and I are saying the same thing, jusst using different words to describe it.
The question was inspired by a forum post where someone was doing exactly that - using a CASE in the order by which would fail on implicit data type conversions. The aim was to highlight the danger of mixing data types in this way - whether it is in an ORDER by or not - but as Hugo says, it mostly happens in ORDER BY clauses.
Also, I just like it when I find something that people may not know and want to share :satisfied:
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
November 19, 2010 at 3:11 am
Just adding my vote to the "good question" list. I'm well aware of data type conversions, and spotted the "trick", and still got it wrong through a moment of fuzzy thinking. Well done on re-highlighting the issue.
November 19, 2010 at 8:52 am
I think the "trap" is that the code "looks" like it is writing dynamic sql, but it really isn't.
November 21, 2010 at 1:42 pm
Although I'm irritated that the flipping of 1 and 2 was very noticeable and having noticed it I decided that was "the trick" and thought no more (thus getting the wrong answer) I still thionk it's a good question. It's very important when desk-checking someone's code or trying to debug something to do it carefully and follow through on the whole thing, not stop thinking when you spot something odd, so questions like this are valuable - they remind us that leaping to conclusions without considering all the code is a stupid thing to do.
Tom
November 22, 2010 at 5:40 am
Excellent question - which I got right due to having been buitten by exactly this problem in the past, and it took ages to track down the cause 🙂
November 24, 2010 at 11:09 am
Thanks for the question.
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
November 25, 2010 at 5:25 am
Thanks for posting this.
I am new to SQL server programming. Though both question and answer was clear i would like to know the reason or why SQL server is performing CONVERT_IMPLICIT(datetime,[Union1007],0).(ie why String1, String2 is converted to datetime).
Thanks
November 25, 2010 at 5:30 am
Gopinath Srirangan (11/25/2010)
Thanks for posting this.I am new to SQL server programming. Though both question and answer was clear i would like to know the reason or why SQL server is performing CONVERT_IMPLICIT(datetime,[Union1007],0).(ie why String1, String2 is converted to datetime).
Thanks
Please see this post for an explanation : http://www.sqlservercentral.com/Forums/FindPost1021495.aspx
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
Viewing 14 posts - 31 through 43 (of 43 total)
You must be logged in to reply to this topic. Login to reply