DugyC (9/13/2012)
Sorry to be pedantic, but I feel I have to in this case.GO, or NotGo, aside not one person can run this complete script without modification or error.
@test-2 is DECLARE'd twice 😛
I want my point! 😀
If you change the SSMS configuration to use NotGo as batch seperator, then the script supplied will contain two batches. In each of those batches, @test-2 is declared exactly once. It should run perfectly. As you would have known if you have started SSMS and tested it. (Don't forget to set the batch seperator back to GO after you finish testing!)
zak_willis (9/13/2012)
We all know that go is an SSMS denotation for separating batches. Effectively, you challenged a system 1 type response that required a system 2 type response. You tricked us into not knowing some extraneous fact about modifying go to not go using osql. Why anybody would configure a particular machine to use notgo rather than go, is beyond me aside from some bizarre security policy. I find this kind of question, pretty much pointless.
I have no idea what type 1 and type 2 responses are, but I disagree with the rest of your reaction. I don't feel tricked at all by this question. The question included the fragments "made to run ... without error" (which communicates that you have to do SOMETHING to achieve that result" and "without changing the script" (implying that everything else is fair game to be changed). So basically, the question is "did you know that you can change the batch seperator".
I agree that the ability to change the batch seperator is quite bizarre and probably quite pointless, but many QotDs are about bizarre and pointless tidbits of knowledge. I consider the QotD as a sort of fun trivia quiz rather than as a measurement of my ability to excell in my job. Many trivia questions are utterly pointless (but fun).
Finally, I can give you one example where this knowledge can be useful: when you have a co-worker whose idea of fun it is to change the batch seperator to, for instance, "SELECT" when you are away from your keyboard, and then watch you struggle to understand why your code is not working anymore. After this QotD, you will probably be able to recognise and fix the problem much faster than you otherwise would have.