December 23, 2010 at 10:54 am
Just the opposite- If you FAILED to patch your server, you got this quesiton right- and failed to patch it EVER since this was fixed in SP1.
Still, interesting behavior for the compiler when dealing with line comments. And I'm willing to bet there are MANY other compilers out there, for a variety of languages, that don't recognize CR/LF, CR, AND LF (sorry, I'm old enough to remember Epson printer coding in the late 1970s- I will NEVER see char(10) as NL instead of LF, even though they have the same meaning- new line or line feed) as end of line. And for those who are actually coding compilers, it's a darn good lesson to remember to test for all three as end of line.
Ted Seeber
I find your secrets in your data.
http://www.informaitonr.us
December 23, 2010 at 1:14 pm
What I got out of this question is that it shows there once was a bug in SQL2K, which was corrected with SP updates years ago. I usually walk away with learning something from the questions, but this one feels like a waste of time.
I have access to a SQL2K, SP4 server with Query Analyzer as well as SQL2K5 9.0.3054 with Management Studio 2005. In both instances I get the following:
What you see...
-----------------------
print 1
-- Comment one
print 2
-- Comment two
print 3
-- Comment three
print 4
is not what you get!
-----------------------
1
2
3
4
December 23, 2010 at 1:28 pm
Not sure what system the author ran the script on, but I ran it in Management Studio 2005 version 9.00.1399.00 and got 1,2,3,4. Also ran it in Management Studio 2008 and got 1,2,3,4.
December 23, 2010 at 2:52 pm
While I find the question slightly pointless, I have to say I'm more than a little surprised that so many got it wrong. The question made it perfectly clear that 1,2,3,4 wouldn't be correct.
As an old hand (and C programmer to boot) I remember quite well that line feed is the most "functional" line separator. That made it resonable to guess the '2' would fall prey to the one line comment.
December 23, 2010 at 3:32 pm
stewartc-708166 (12/23/2010)
Tom.Thomson (12/23/2010)
stewartc-708166 (12/23/2010)
Having investigated this further, I have found that the "correct" answer occurs on SQL2000 and SQL2005 RTM.this was registered as a bug and repaired with CU2 of SQL2005 (also included in service pack 1).
So MS had it right (CR does not terminate a -- comment) and some nitwit reported this as a bug and MS was sufficiently stupid to "fix" it? Oh mo chreach!
par for the course....
CR was a placemarker character, left over from the old typeset days, which told the typesetter to go to the begining of a line (or the first available space thereafter). It was thus used in conjunction with the NL character which, without it, would cause the cursor to go to the next line, but continue from the same position.
Not quite, because NL and LF are not the same character and ASCII has no NL character (the reference to the old typeset days is incorrect too - there was no CR in manual typesetting, although there was in typing).
Back in the bad old days (early 60s, before there were reasonable coding standards) encoding standards were going in two directions: IBM was devising 8-bit EBCDIC (based on IBM's 6-bit BCD) while ECMA and ASA were devising 7-bit ECMA-6 and 7-bit ASCII (with only very minor differences) mainly based on ECMA-1 (another 6 bit code) with noticeable influence from the CCITT coding standard for control characters. The ASCII and ECMA 7 bit codes were convenient for transmission using 7 bits (either with a parity bit added to improve error detection or without to get a 12.5% required bandwidth reduction) , while IBM's 8-bit code wasn't but could represent more characters. But the part of this divergence that affects the discussion here was that the two groups (IBM and followers with EBCDIC, the rest with ASCII/ECMA) had different views of line feed, carriage return, and newline: ASCII had only the first two characters (CR and LF) while EBCDIC had all three. This gave EBCDIC barrel printers (using NL) a tiny advantage over ASCII barrel printers (using CR-LF) which caused some people to start treating ASCII LF as if it were NL, to recover this tiny edge, but in fact that gave EBCDIC printers a different advantage of ASCII barrel printers which did this (because they now had to received LF plus a wodge of spaces where the EBCDIC printers just needed LF).
It is incorrect for a parser to treat CR as End of Line in either ASCII or EBCDIC, because it provides for overprinting on the same line; in some languages this is irrelevant, because EoL never has any syntactic significance beyond being white space, so no EoL detection is needed anyway and the parser doesn't detect EoL; in the case of SQL, CR provides for overprinting in a comment introduced by --, and in the context of a comment introduced by -- EoL has syntactic significance beyond being white space so the parser has to detect it. MS treating CR as EoL in this context is a bug; it is not and never was a bug fix, it was a foolishly introduced bug which spoiled previously correct code.
Tom
December 23, 2010 at 4:14 pm
Check your answer properly before submitting a question, because your so-called "correct answer" is wrong.
And so:
1. Go to the back of the class;
2. stand in the corner;
3. And wear a dunce's hat for three hours.
And see me after school.
And give me my point Mr Steve Thingimygig.
Ken.
You never know: reading my book: "All about your computer" might just tell you something you never knew!
lulu.com/kaspencer
December 23, 2010 at 11:45 pm
By the way, they say in BOL 2008:
Each Transact-SQL statement should be terminated with a semicolon. This requirement is not enforced, but the ability to end a statement without a semicolon is deprecated and may be removed in a future version of Microsoft SQL Server.
December 23, 2010 at 11:59 pm
hi, i got answer 1,2,3,4
December 24, 2010 at 2:11 am
Rune Bivrin (12/23/2010)
While I find the question slightly pointless, I have to say I'm more than a little surprised that so many got it wrong. The question made it perfectly clear that 1,2,3,4 wouldn't be correct.
The question did indeed make it clear that it wouldn't be 1,2,3,4. I couldn't work out by looking at it how it could give any other answer, so I ran it and got 1,2,3,4.
That's how I got it wrong, and I assume that most people will have done something similar. Therefore I'm surprised that so many people got it right! There must be more people still using unsupported versions than I'd have predicted.
December 24, 2010 at 4:27 am
mtassin (12/23/2010)
Just FYI, different Operating systems do it differently anyway.
I'm pretty sure Unix/Linux doesn't put both CR and LF (Carriage Return and Line Feed) characters at the end of a line in a text file.
It doesn't, and neither did the Mac (even before it became UNIX derived with Mac OS X). However, I think they both use LF alone (0xA) as the line terminator--I've never encountered an OS that uses CR alone as a line terminator, but there may well be one out there!
December 27, 2010 at 2:11 pm
'Question of the day' is definitely such a favorite for so many. This is my second time in less than a month having lost points in spite of having answered in accordance with the output in SQL Server. The first time, the points were granted. Hope is still alive for this one!
😉
What you see...
-----------------------
print 1
-- Comment one
print 2
-- Comment two
print 3
-- Comment three
print 4
is not what you get!
-----------------------
1
2
3
4
December 28, 2010 at 11:11 am
Only correct for 2005 RTM? Can't say as I like this question...
December 28, 2010 at 12:31 pm
I too get 1, 2, 3, 4.
December 28, 2010 at 3:54 pm
Using SQL SMSS 2008 I got 1,2,3,4 as well...
I have run into similar problems using -- as a commenting method, though never in SMSS. Once my sql scripts are implemented (as is specific to my employer), they are executed in their entirety as a single line. This causes ALL code after the --'s to become disabled. When comments are necessary in my scripts, I use /* to make my comments */ and avoid this problem.
December 29, 2010 at 5:54 am
Dear friends:
I'm a little disappointed after reading the comments of this forum. Few people have liked or commented on the anomalous behavior described, and most, rude apart, are concentrated in two categories:
1) Give me back my point.
2) Have had the SP updated.
With the former, I apologized a few posts back for the disgust. Formally, it is true that the question is misleading. However, I do not agree with them that the game point lost is more relevant than the fact of learning something, even something you think that never in life is going to happen. In short, I think that curiosity must be above the game, but hey, it's my personal opinion.
For the latter, also explained above the reasons why the SP is not updated (for those not wishing to look for, suffice to say that our servers are outsourced. The administration is out of reach, and we can only report the situation , which we have already done.) Thank you for the information on the nature of the problem and its possible solution by updating. However, it goes without being condescending, because no match will guarantee you will not find one day a problem you don't know how to solve, and you'll like a sympathetic attitude (I suppose).
I have spent many years programming, I suffered a lot of headaches, especially in the beginning when everything was more handmade and generally incompatible. Now the problems are usually more routine, but every once in a while you find something like this, flashy, and then I feel surprised as a kid when we find the solution. That surprise is what I would have like to share with you and only a few have appreciated it, which I regret.
Without acrimony, greetings to all of you,
Viewing 15 posts - 46 through 60 (of 66 total)
You must be logged in to reply to this topic. Login to reply