After seeing all these comments about what should have been implied and what was inferred, I can't tell you the number of times these QotD have been trick questions, trying to 'get you' with slight and small syntax errors or db assumptions, intentionally generating an error message.

Just because someone ran the code and got an error message does not mean the error message was not the correct answer.

In this case, an error message was not option 'D', so I proceeded with the assumption that at least one of the three generated correct results.

OK, I answered C because A and B are so completely wrong that C is the only option where we can reasonably guess that the setter of the question got it wrong enough to think C would work. So I got my point - for understanding the sort of stupid error that the question setter would make, not for producing a correct answer (because "(D) none o the above" is the correct answer, but not available). This is a really bloody awful question and answer.I'm seeing far too much of thios sort or thing in QOD. Presumably it's completely unmoderated?

map @tablevariable to one of your database table, select that database as current database and then execute the code

No, and it wouldn't help if I did. I don't have a table called 'any valid table name' in any database on my server. (I know that sounds nasty - but the provocation was extreme!)

Claiming that this is a sensible question with a sensible answer because it's obvious that unless you change the question all the answers are wrong is just nonsense. Yes, there are real life situations like that (the requirement as provided is nonsense), but in those situations you should not guess what part of the question (requirement) you have to change, you should throw the thing back at whoever provided the question and point out that it's nonsense. Otherwise you risk finding yourself spending a lot of effort on doing something completely useless, because you guessed wrong. And in practise, no matter how obvious it looks to you what the required modification is, you are NOT the person who understands the business inside out and specifies the requirement, so your guess will often be wrong. (If you were the person with that knowledge and understanding, you would be writing the requirement, and would not make silly errors like that - I hope.)

Tom.Thomson (2/9/2010)OK, I answered C because A and B are so completely wrong that C is the only option where we can reasonably guess that the setter of the question got it wrong enough to think C would work. So I got my point - for understanding the sort of stupid error that the question setter would make, not for producing a correct answer (because "(D) none o the above" is the correct answer, but not available). This is a really bloody awful question and answer.I'm seeing far too much of thios sort or thing in QOD. Presumably it's completely unmoderated?

map @tablevariable to one of your database table, select that database as current database and then execute the code

No, and it wouldn't help if I did. I don't have a table called 'any valid table name' in any database on my server. (I know that sounds nasty - but the provocation was extreme!)

Claiming that this is a sensible question with a sensible answer because it's obvious that unless you change the question all the answers are wrong is just nonsense. Yes, there are real life situations like that (the requirement as provided is nonsense), but in those situations you should not guess what part of the question (requirement) you have to change, you should throw the thing back at whoever provided the question and point out that it's nonsense. Otherwise you risk finding yourself spending a lot of effort on doing something completely useless, because you guessed wrong. And in practise, no matter how obvious it looks to you what the required modification is, you are NOT the person who understands the business inside out and specifies the requirement, so your guess will often be wrong. (If you were the person with that knowledge and understanding, you would be writing the requirement, and would not make silly errors like that - I hope.)

Becasue all the code options povide produce an error or NULL. Now if you think that an error or NULL is the expected result, then one of them may be right and it might be C. I thought that the expected result was some useful data, not an error message or NULL, so that none of the suggested answers produced the expected result. I may have been wrong - maybe case C produced the expected error message, in which case I have to ask why that error message rather than the result of A or B is the expected result. Do you have an answer for that? Or are you taking the rather arrogant view that because you don't like the question you will reformulate it to mean something different (perhaps something more fully specified) rather than refer it back to the poser?

Lynn Pettis (2/9/2010)Explain to me why you think each of the answers is wrong.

Because each answer tries to select from a table with a particular name in an completely unspecified database. That table probably doesn't exist in most databases (it doesn't exist in any DB on any server I ever controlled - and I'll leave you to guess whether that means that I never controlled an HR or Payroll DB or that the table just happened to be named "seirbhiseach" or "Angestellte" instead of "employee".

In the real world it's no good doing what the commenter to whom I was replying suggested - just pick any database you have and then pick any table you have in that DB and then make the query refer to that table - whoever produced the requirement had something in mind, and surely it wasn't to let the developer pick the database and table at random. OK, so here we are talking about QOD instead of about real requirements, and the standard of questions is sometimes pretty low so adjusting the question might often make sense - but as a general rule I think we should try to treat the questions as if they are hard and fast, not subject to adjustment without obtaining agreement from the poser, because in the real world all the badly formulated (and often completely wrong-headed) requirements we see have to go through that negotiate with the poser process.