InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 10:53:03 GMT20http://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxnice oneThu, 02 Aug 2012 08:36:22 GMTBudaClihttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxGreat question, thanks!Mon, 05 Dec 2011 01:15:41 GMTKoen Verbeeckhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]L' Eomot Inversé (12/1/2011)[/b][hr][quote][b]Hugo Kornelis (12/1/2011)[/b][hr][quote][b]Carla Wilson-484785 (12/1/2011)[/b][hr]I really don't understand why someone would want to do a comparison that is based on the data type.[/quote]Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.[/quote]Given that they wanted people to be able to construct indexes on sql_variant columns, they didn't have a choice - they had to provide a total order on SQL_VARIANTs. Not allowing it at all was not an option.[/quote]Thanks, that makes sense.[quote][b]L' Eomot Inversé (12/1/2011)[/b][hr][quote][b]Hugo Kornelis (12/1/2011)[/b][hr][quote]The lesson I learn from this is to not do comparisons on sql_variant.[/quote]Amen to that![/quote]Yes, Amen to that from me too - as far as I am concerned, the only real uses for SQL_VARIANT ordering are (i) to support indexes and unique constraints and (ii) to provide material for technical trivia questions like this one.[/quote]Fair enough! (thanks for the explanations!) :-PFri, 02 Dec 2011 13:40:55 GMTCarla Wilson-484785http://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Hugo Kornelis (12/1/2011)[/b][hr][quote][b]Carla Wilson-484785 (12/1/2011)[/b][hr]I really don't understand why someone would want to do a comparison that is based on the data type.[/quote]Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.[/quote]Given that they wanted people to be able to construct indexes on sql_variant columns, they didn't have a choice - they had to provide a total order on SQL_VARIANTs. Not allowing it at all was not an option.[quote]They chose the former, and then had to come up with a way to compare the numeric value 15, the string value N'fünfzehn', the date December 1st, 2011, and the bit value 1. Which one is more than the others? And why? They had to make a choice - but whatever their choice was, it was bound to be perceived as wrong for some cases.That being said, I do share your amazement at the choice to put exact and inexact numerics in two different groups. It appears this choice was born out of technical rather than functional considerations.[/quote]I can't really think of any purely "technical" considerations that would suggest making them two separate type families; perhaps an awareness that conversion from exact to inexact numerics (which is the conversion that would have to be done to allow comparison if they were in the same group) can cause bizarre rounding effects (as can the conversion in the opposite direction, of course) could be considered a technical consideration but I would consider avoiding such effects as a fundamental requirement of indexing (and in particular of having UNIQUE constraints supported by indexes) so I see it as rather an essential requirement of the SQL data model rather than something merely "technical".[quote][quote]The lesson I learn from this is to not do comparisons on sql_variant.[/quote]Amen to that![/quote][/quote]Yes, Amen to that from me too - as far as I am concerned, the only real uses for SQL_VARIANT ordering are (i) to support indexes and unique constraints and (ii) to provide material for technical trivia questions like this one.Thu, 01 Dec 2011 12:48:06 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Carla Wilson-484785 (12/1/2011)[/b][hr]I really don't understand why someone would want to do a comparison that is based on the data type.[/quote]Well, I guess the issue is that the SQL Server development team had to choose between allowing > and < comparisons for sql_variant (and makinig it work in all cases), or not allowing it at all.They chose the former, and then had to come up with a way to compare the numeric value 15, the string value N'fünfzehn', the date December 1st, 2011, and the bit value 1. Which one is more than the others? And why? They had to make a choice - but whatever their choice was, it was bound to be perceived as wrong for some cases.That being said, I do share your amazement at the choice to put exact and inexact numerics in two different groups. It appears this choice was born out of technical rather than functional considerations.[quote]The lesson I learn from this is to not do comparisons on sql_variant.[/quote]Amen to that!Thu, 01 Dec 2011 08:15:43 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Toreador (11/30/2011)[/b][hr][quote][b]KWymore (11/30/2011)[/b][hr]I am curious how many out there are utilizing sql_variant and under which circumstances?[/quote]I've used it for generic audit tables, where we store something like table name, column name, old value, new value - the old/new values are sql_variant as they could be any data type.Of course you'd never do any comparisons between different data types in these circumstances.[/quote]Toreador, thanks! I, too, was wondering where one would use sql_variant - now it seems obvious.That said, I appreciate David Data's comment:[quote][b]David Data (12/1/2011)[/b][hr]I see that even if you set[quote] @v1 sql_variant = cast ('15.00' as float(53)), @v2 sql_variant = cast ('16.00' as decimal(18,4)),[/quote]which makes[quote]v1 v215 16.0000[/quote]SQL Server [b]still[/b] says v1 > v2.This behaviour is very counter-intuitive - to say nothing of being arithmetically incorrect!It would be better if it produced the result one would expect - or if it won't, if it [i]refused[/i] to do such comparisons. I can imagine many data errors being caused by people not noticing this behaviour and believing the wrong results they get.[/quote]I really don't understand why someone would want to do a comparison that is based on the data type. I can only guess that they chose to set it up this way to avoid errors that might occur in implicit conversions. The lesson I learn from this is to not do comparisons on sql_variant.Thu, 01 Dec 2011 07:50:45 GMTCarla Wilson-484785http://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxGood question, but a lot of reading. Thanks for submitting.Thu, 01 Dec 2011 06:09:18 GMTBritt Cluffhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxI see that even if you set[quote] @v1 sql_variant = cast ('15.00' as float(53)), @v2 sql_variant = cast ('16.00' as decimal(18,4)),[/quote]which makes[quote]v1 v215 16.0000[/quote]SQL Server [b]still[/b] says v1 > v2.This behaviour is very counter-intuitive - to say nothing of being arithmetically incorrect!It would be better if it produced the result one would expect - or if it won't, if it [i]refused[/i] to do such comparisons. I can imagine many data errors being caused by people not noticing this behaviour and believing the wrong results they get.Thu, 01 Dec 2011 04:19:40 GMTDavid Datahttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx:w00t:In the interest of being exact, the answers given transpose the 3rd field so there was not exactly correct answer given... Here is the result:v1 > v2 v1 > v3 v3 = v2 v4 > v1Wed, 30 Nov 2011 12:09:19 GMTTom_Sacramentohttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]SQLRNNR (11/30/2011)[/b][hr][quote][b]Stuart Davies (11/30/2011)[/b][hr][quote][b]KWymore (11/30/2011)[/b][hr]Interesting question. My brain did the auto translation that v3=v2 was the same as v2=v3 so I didn't even notice that error until I hit the posts here! [/quote]+1[/quote]+1[/quote]+1Wed, 30 Nov 2011 09:53:20 GMTRevenanthttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Stuart Davies (11/30/2011)[/b][hr][quote][b]KWymore (11/30/2011)[/b][hr]Interesting question. My brain did the auto translation that v3=v2 was the same as v2=v3 so I didn't even notice that error until I hit the posts here! [/quote]+1[/quote]+1Wed, 30 Nov 2011 09:28:22 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]KWymore (11/30/2011)[/b][hr]Interesting question. My brain did the auto translation that v3=v2 was the same as v2=v3 so I didn't even notice that error until I hit the posts here! [/quote]+1Wed, 30 Nov 2011 09:22:06 GMTStuart Davieshttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Toreador (11/30/2011)[/b][hr][quote][b]KWymore (11/30/2011)[/b][hr]I am curious how many out there are utilizing sql_variant and under which circumstances?[/quote]I've used it for generic audit tables, where we store something like table name, column name, old value, new value - the old/new values are sql_variant as they could be any data type.Of course you'd never do any comparisons between different data types in these circumstances.[/quote]That is a good use - thanks for posting that. I will have to explore that use.Wed, 30 Nov 2011 09:00:29 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Hugo Kornelis (11/30/2011)[/b][hr][quote][b]Gerardo Galvan Castro (11/30/2011)[/b][hr]In the e-mail newsletter the QotD did not state it was for SQL Server 2008 and later, so I tested under SQL Server 2005 (the only version I have available to use), which would not allow me to run it because "you cannot assign a default value to a local variable", so i chose "None of the above" just to find out it was meant to be run under SQLS 2K8.[/quote]I'd say, with both SQL Server 2008 and SQL Server 2008R2 released and SQL Server 2012 around the corner, it is safe to assume that [b]question are about SQL Server 2008/2008R2 unless specified otherwise[/b].[/quote]Agreed.Wed, 30 Nov 2011 08:59:29 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxTks Tom for the questionWed, 30 Nov 2011 08:54:36 GMTOzYbOi d(-_-)bhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]KWymore (11/30/2011)[/b][hr]I am curious how many out there are utilizing sql_variant and under which circumstances?[/quote]I've used it for generic audit tables, where we store something like table name, column name, old value, new value - the old/new values are sql_variant as they could be any data type.Of course you'd never do any comparisons between different data types in these circumstances.Wed, 30 Nov 2011 08:54:19 GMTToreadorhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxThanks for the question.Wed, 30 Nov 2011 08:53:53 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]KWymore (11/30/2011)[/b][hr]I have not yet seen sql variants actually used in production but then again, we have very few 2008 instances up and running.[/quote]There is no connection between sql_variant and SQL Server 2008. This data type has been around since at least SQL Server 2000. (I think even before that, but I could not find evidence of that, and I'm not sure if I can trust my memory anymore).Wed, 30 Nov 2011 08:49:22 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxInteresting question. My brain did the auto translation that v3=v2 was the same as v2=v3 so I didn't even notice that error until I hit the posts here! I have not yet seen sql variants actually used in production but then again, we have very few 2008 instances up and running. I am curious how many out there are utilizing sql_variant and under which circumstances?Wed, 30 Nov 2011 08:39:31 GMTKWymorehttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Gerardo Galvan Castro (11/30/2011)[/b][hr]Tom, In the e-mail newsletter the QotD did not state it was for SQL Server 2008 and later, so I tested under SQL Server 2005 (the only version I have available to use), which would not allow me to run it because "you cannot assign a default value to a local variable", so i chose "None of the above" just to find out it was meant to be run under SQLS 2K8. Just make sure the specifics are included in the newsletter.Thank you,GG.[/quote]I should have included the version information in the original question. I didn't, so it didn't get into the newsletter - and everyone who answered up to about 10 minutes ago (when the question on the website was corrected) didn't get any version information whichever way the came to the question. My fault, and no valid excuses.But it's a good idea if coming from the newsletter to check that the version on teh website is the same - errare est humanum and all that, and corrections can be applied to the website but can't be applied to the newsletter once it's gone out.Wed, 30 Nov 2011 08:01:05 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Gerardo Galvan Castro (11/30/2011)[/b][hr]In the e-mail newsletter the QotD did not state it was for SQL Server 2008 and later, so I tested under SQL Server 2005 (the only version I have available to use), which would not allow me to run it because "you cannot assign a default value to a local variable", so i chose "None of the above" just to find out it was meant to be run under SQLS 2K8.[/quote]I'd say, with both SQL Server 2008 and SQL Server 2008R2 released and SQL Server 2012 around the corner, it is safe to assume that question are about SQL Server 2008/2008R2 unless specified otherwise.Wed, 30 Nov 2011 07:59:22 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxTom, In the e-mail newsletter the QotD did not state it was for SQL Server 2008 and later, so I tested under SQL Server 2005 (the only version I have available to use), which would not allow me to run it because "you cannot assign a default value to a local variable", so i chose "None of the above" just to find out it was meant to be run under SQLS 2K8. Just make sure the specifics are included in the newsletter.Thank you,GG.Wed, 30 Nov 2011 07:48:42 GMTEL Jerryhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxThe question now reader:====[code="sql"]Assuming you have a database called playpen on SQL Server 2008 and above, what is the resul of the select statement in the following code?use playpengobegindeclare @v1 sql_variant = cast ('15.00' as float(53)), @v2 sql_variant = cast ('15.00' as decimal(18,4)), @v3 sql_variant = cast ('15' as tinyint), @v4 sql_variant = cast ('00:00:15.00' as time) select case when @v1 > @v2 then 'v1 > v2' when @v2 > @v1 then 'v2 > v1' else 'v2 = v1' end, case when @v1 > @v3 then 'v1 > v3' when @v3 > @v1 then 'v3 > v1' else 'v3 = v1' end, case when @v2 > @v3 then 'v2 > v3' when @v3 > @v2 then 'v3 > v2' else 'v2 = v3' end, case when @v1 > @v4 then 'v1 > v4' when @v4 > @v1 then 'v4 > v1' else 'v4 = v1' endend[/code]====And the answers corrected to:A: v2 = v1, v3 = v1, v2 = v3, v4 = v1B: error indicating float and time are incompatibleC: v1 > v2, v1 > v3, v3 > v2, v4 > v1D: v1 > v2, v1 > v3, v2 = v3, v4 > v1E: v2 = v1, v1 > v3, v2 > v3, v1 > v4F: none of the above====v2=v3 matches in answers A and DPoints have been awarded back to everyone to this point.Wed, 30 Nov 2011 07:46:38 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]rfr.ferrari (11/30/2011)[/b][hr]good question and explanation!!!!thanks Tom!!![/quote]But terrible answer!!Wed, 30 Nov 2011 07:15:28 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]callie97 (11/30/2011)[/b][hr]I got this question 'wrong' because the result of my query came back with v3 = v2, not v2 = v3. The value in the result set is a text value. That means that 'v3 = v2' is not the same as 'v2 = v3'. While mathematically it is the same, we are talking about the value of the result set as a text field. If you had not used the comparison as the returned set and had instead used Adam, Betty, Charlie or Apple, Banana, Grape to indicate which When clause had been validated as being true it would be very clear that Betty does not equal Banana. Or, if the when clause that evaluated to true was the percentage of your raise, then you are saying you would be happy with 1.0% instead of 10% because as you pointed out, it doesn't effect anyone's points if they choose None of the Above instead of the row with the typo. I've chosen wrong answers before because of small mistakes like this so I check my result set very carefully with the choices. If this had been code that had gone to production with a small typo in the When clause, it can make for even bigger issues. [/quote]You are right, there wa a typo in the option list as well as in the answer. It was absolutely stupid of me to miss that when checking as a result of the first comment this morning, and it does indeed affect people's points.Steve will be correcting it and awarding points to people who lost them through my errors.Wed, 30 Nov 2011 07:13:59 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxI got this question 'wrong' because the result of my query came back with v3 = v2, not v2 = v3. The value in the result set is a text value. That means that 'v3 = v2' is not the same as 'v2 = v3'. While mathematically it is the same, we are talking about the value of the result set as a text field. If you had not used the comparison as the returned set and had instead used Adam, Betty, Charlie or Apple, Banana, Grape to indicate which When clause had been validated as being true it would be very clear that Betty does not equal Banana. Or, if the when clause that evaluated to true was the percentage of your raise, then you are saying you would be happy with 1.0% instead of 10% because as you pointed out, it doesn't effect anyone's points if they choose None of the Above instead of the row with the typo. I've chosen wrong answers before because of small mistakes like this so I check my result set very carefully with the choices. If this had been code that had gone to production with a small typo in the When clause, it can make for even bigger issues. Wed, 30 Nov 2011 07:07:43 GMTcallie97http://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Cadavre (11/30/2011)[/b][hr][quote][b]L' Eomot Inversé (11/30/2011)[/b][hr]I replied too quickly before, didn't cover all bases before getting it wrong. I knew there wasn't a typo in the question, and didn't consider the possibility of one in the answer so didn't compare the anser with the options in the question. Thus compounding my error - the misprint was bad enough, then saying there wasn't one was worse. Mea maxima culpa :blush:The only consolation is that it didn't affect anyone's score - as is made clear by the image you attached, 51% of people got it right and were recognised as having it right even though the option they chose didn't match the row given in the answer.[/quote]Hmm, I can't view the original question now so can't see the original options but I'm sure the reason I selected "None of the above" was because the option that most closely resembled the answer stated v2=v3 not v3=v2.Never mind, the explanation was good :-D[/quote]My God, I must be going crazy.A big apology from me to everyone. :blush: :blush: :blush: :blush: :blush: :blush:The typo in the answer is matched by the typo in the question. Not the bit of the question I could see in the newsletter (it doesn't show me the bits not visible to me on the website, which Of course I should have noticed :blush: :blush:, but as you have pointed out it soes in the bit I could see by looking at the numbers of responses!) The only correct answer was "none of the above"!I'll ask Steve to fix it - so far I've asked him to change the answer and add version info to the question, now I'm asking him for another change. I guess he will award points back.Wed, 30 Nov 2011 06:54:46 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]L' Eomot Inversé (11/30/2011)[/b][hr]I replied too quickly before, didn't cover all bases before getting it wrong. I knew there wasn't a typo in the question, and didn't consider the possibility of one in the answer so didn't compare the anser with the options in the question. Thus compounding my error - the misprint was bad enough, then saying there wasn't one was worse. Mea maxima culpa :blush:The only consolation is that it didn't affect anyone's score - as is made clear by the image you attached, 51% of people got it right and were recognised as having it right even though the option they chose didn't match the row given in the answer.[/quote]Hmm, I can't view the original question now so can't see the original options but I'm sure the reason I selected "None of the above" was because the option that most closely resembled the answer stated v2=v3 not v3=v2.Never mind, the explanation was good :-DWed, 30 Nov 2011 06:40:47 GMTCadavrehttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Cadavre (11/30/2011)[/b][hr][quote][b]Cadavre (11/30/2011)[/b][hr]Got it wrong because I believe it should say "v3 = v2" not "v2 = v3"[/quote][quote][b]L' Eomot Inversé (11/30/2011)[/b][hr][quote][b]wloong (11/29/2011)[/b][hr]I agreed! From the programming logic, "v2 = v3" could not be displayed! In fact, the right answer should be "None of the above". If the editor admit that it is a typo mistake, then both "v2 = v3" and "None of the above" should be correct in order to be fair.[/quote]There isn't a typo. The select statement as written can't return v2=v3 in any of ths ecolumns of the resulting row: as you yourself state, the programming logic does not permit v2 = v3 to be displayed, so how could it imaginably be correct to say it return v2 = V3 in one of the columns? If you run the code you will certaily see that "none of the above" is not the correct answer, because it returns one of the rows listed.[/quote]Yes Tom, but the "correct" answer states v2=v3 not v3=v2.[URL=http://imageshack.us/photo/my-images/839/typoh.png/][IMG]http://img839.imageshack.us/img839/7516/typoh.png[/IMG][/URL][/quote]I replied too quickly before, didn't cover all bases before getting it wrong. I knew there wasn't a typo in the question, and didn't consider the possibility of one in the answer so didn't compare the anser with the options in the question. Thus compounding my error - the misprint was bad enough, then saying there wasn't one was worse. Mea maxima culpa :blush:[strike]The only consolation is that it didn't affect anyone's score - as is made clear by the image you attached, 51% of people got it right and were recognised as having it right even though the option they chose didn't match the row given in the answer.[/strike]Must check more carefully before rplying in future :blush:Wed, 30 Nov 2011 06:34:50 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxNot listed as an excuss. I'm in a shop where we have not moved any critcal systems to SQL 2008R2 let alone thinking about 2012. The fact is that the data type is not avail.Wed, 30 Nov 2011 06:32:44 GMTgary.mazzonehttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]gary.mazzone (11/30/2011)[/b][hr]Since the version is not specified if this is run on SQL Server 2005 then the Answer needs to be None of the above. Why do we ask.... Time is not a valid system type in SQL Server 2005 and is only avail in 2008 and above. Way was that not specified in the QOD?[/quote]I guess it should have been. My fault, I should have included the version in the question. The only excuse I have is that SQL 2008 is pretty old now, even SQL 2008 R2 is not as new as it used to be (and is the only version I now use). But it's not a good excuse, because I skipped direct from 2000 to 20008 didn't use 2005, so I expect there to be people who skip direct from 2005 to 2012 and never use 2008.Wed, 30 Nov 2011 06:27:49 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Hugo Kornelis (11/30/2011)[/b][hr]Tom, please double check the question. The SQL text contains the string constant 'v3 = v2' as one of the CASE results. The correct answer option reads v2 = v3. As you can see, the order of the two variable names is reversed.The intention is very clear, but all the people who commented that this is a typo and that the answer is technically incorrect are in fact right.[/quote]Yes, you are right Hugo. [strike]Fortunately it doesn't affect the result - there's no typo in the question, only in the answer, so people who get it right (pick the right option, not the row incorrectly given as the answer which they can't pick anyway as it's not one of the options) get their points and people who get it wrong don't. I imagine most people who get it right don't look at the row in teh answer and don't notice the misprint, but it's certainly irritating for those who get it wrong (perhaps by picking a random option in order to see the answer) so I'm asking Steve to fix the answer text.[/strike]There were two misprints (matching each other) which means that scores were affected.Wed, 30 Nov 2011 06:22:57 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Henrico Bekker (11/30/2011)[/b][hr][quote]Hi Tom, if the question is "what would the statement return" then "v3=v2" is in fact correct, because that is what is returned when executing the code.I have read the question, thats why I didnt see 'v2=v3' being returned. My point is, the correct answer involves text that wasnt in the question, as it was hardcoded text, and executing it like you posted it would not return what you set as the right answer.[/quote]You must have read my reply while I was editing it - that was pretty fast reaction! I had to go to the newsletter to check the text of the question, because of course once I start looking at comments I can no longer see the text on the website, but that was the only delay after I had realised I needed to check again immediately on hitting th epost button. Yes, there is indeed a misprint in the answer, and my first reply must have come over as arrogant twaddle until I edited it. :blush:[strike]However, the misprint in the answer doesn't affect anyone's points, because what's in the answer isn't the option you have to select (it isn't even an option) and the correct option is there in the questiopn and you get the points if you select it.[/strike] There's a matching misprint in the options listed too. :blush: blush: blush:Wed, 30 Nov 2011 06:17:03 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Thomas Abraham (11/30/2011)[/b][hr]Good question, excellent explanation. Now please explain:[quote]Crois-tu qu'on s'enivre pour s'amuser? Etre ivrogne ce n'est pas une sinécure... Si tu savais l'attention et la persévérance qu'il faut! Toujours à remplir des verres et à les vider. On vous prend pour un riche oisif, en fait c'est un travail de plongeur.[/quote]I was curious when I saw "plonguer", even though I don't speak French. (German, Greek, and Spanish, but no French) The word caught my eye because, in my misspent youth, I read "Down and Out in Paris and London", where, I believe, Orwell was a "plonguer" - the lowest of the low - a dishwasher. Or, am I fooled by a similar word? (The rest of the sig line I was able to translate using an online translator. But, it translated "plonguer" to "diver", which didn't seem to fit the context.)Later: Duh, must be a slang use of the word for diver in reference to diving into the sink after dishes! Too literal this morning.[/quote]Your first guess was correct - a slang term for dishwasher (actually underpaid dishwasher, it dates from the era when most restaurant staff in most restaurants in France weren't paid by the restaurant - a dishwasher got a share of the waiters' tips, not a big one, in many restaurants the waiters had to pay the proprietor for the privilege of having the waiting job and the chance to earn tips so they didn't want to share much.Wed, 30 Nov 2011 06:10:10 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]Cadavre (11/30/2011)[/b][hr]Got it wrong because I believe it should say "v3 = v2" not "v2 = v3"[/quote][quote][b]L' Eomot Inversé (11/30/2011)[/b][hr][quote][b]wloong (11/29/2011)[/b][hr]I agreed! From the programming logic, "v2 = v3" could not be displayed! In fact, the right answer should be "None of the above". If the editor admit that it is a typo mistake, then both "v2 = v3" and "None of the above" should be correct in order to be fair.[/quote]There isn't a typo. The select statement as written can't return v2=v3 in any of ths ecolumns of the resulting row: as you yourself state, the programming logic does not permit v2 = v3 to be displayed, so how could it imaginably be correct to say it return v2 = V3 in one of the columns? If you run the code you will certaily see that "none of the above" is not the correct answer, because it returns one of the rows listed.[/quote]Yes Tom, but the "correct" answer states v2=v3 not v3=v2.[URL=http://imageshack.us/photo/my-images/839/typoh.png/][IMG]http://img839.imageshack.us/img839/7516/typoh.png[/IMG][/URL]Wed, 30 Nov 2011 05:58:33 GMTCadavrehttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxRemoved.I must learn to read first, write later. Sorry!Wed, 30 Nov 2011 05:57:32 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxTom, please double check the question. The SQL text contains the string constant 'v3 = v2' as one of the CASE results. The correct answer option reads v2 = v3. As you can see, the order of the two variable names is reversed.The intention is very clear, but all the people who commented that this is a typo and that the answer is technically incorrect are in fact right.Wed, 30 Nov 2011 05:56:00 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxSince the version is not specified if this is run on SQL Server 2005 then the Answer needs to be None of the above. Why do we ask.... Time is not a valid system type in SQL Server 2005 and is only avail in 2008 and above. Way was that not specified in the QOD?Wed, 30 Nov 2011 05:55:45 GMTgary.mazzonehttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspx[quote][b]L' Eomot Inversé (11/30/2011)[/b][hr][quote][b]Henrico Bekker (11/29/2011)[/b][hr]even though x=y, and y=x, your case statement catered for the following result:[code="sql"]'v3 = v2'[/code] and no where specifies v2=v3."None of the Above" should be correct as well.[/quote]The question is what does the select statement return, not what could some different select statement have returned, so I think perhaps you should look again and try to understand teh question properly.[/quote]Hi Tom, if the question is "what would the statement return" then "v3=v2" is in fact correct, because that is what is returned when executing the code.I have read the question, thats why I didnt see 'v2=v3' being returned. My point is, the correct answer involves text that wasnt in the question, as it was hardcoded text, and executing it like you posted it would not return what you set as the right answer.Wed, 30 Nov 2011 05:53:57 GMTHenrico Bekkerhttp://www.sqlservercentral.com/Forums/Topic1213644-2681-1.aspxerroneous postWed, 30 Nov 2011 05:51:45 GMTL' Eomot Inversé