Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««34567»»»

Subtle Line Feed / Carriage Return issue Expand / Collapse
Author
Message
Posted Thursday, December 23, 2010 8:24 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, January 21, 2014 9:03 AM
Points: 4, Visits: 16
Bug must be fixed in 2008:
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
Post #1038809
Posted Thursday, December 23, 2010 8:27 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, January 21, 2014 9:03 AM
Points: 4, Visits: 16
Only if you've failed in the server patch department- this was fixed SQL Server 2005 SP1
Post #1038812
Posted Thursday, December 23, 2010 8:58 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 7:44 PM
Points: 21,209, Visits: 14,899
Thanks for the question. It would have been nice to have something a little more current.



Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1038829
Posted Thursday, December 23, 2010 9:26 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 4:28 AM
Points: 1,100, Visits: 4,898
I also got 1,2,3,4 so not sure what the question was trying to show - no bug here!
Post #1038854
Posted Thursday, December 23, 2010 10:01 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, October 25, 2013 7:43 AM
Points: 1,384, Visits: 644
the question would have been alright in 2005 when that was an issue

so the only people to get the question right were people have fully patched sql 2005



Post #1038875
Posted Thursday, December 23, 2010 10:54 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, January 21, 2014 9:03 AM
Points: 4, Visits: 16
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.
Post #1038891
Posted Thursday, December 23, 2010 1:14 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 4, 2011 4:12 PM
Points: 92, Visits: 12
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
Post #1038931
Posted Thursday, December 23, 2010 1:28 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 10:16 AM
Points: 1,015, Visits: 98
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.
Post #1038939
Posted Thursday, December 23, 2010 2:52 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:21 AM
Points: 2,988, Visits: 901
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.



Just because you're right doesn't mean everybody else is wrong.
Post #1038955
Posted Thursday, December 23, 2010 3:32 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: 2 days ago @ 10:00 AM
Points: 8,551, Visits: 9,043
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
Post #1038960
« Prev Topic | Next Topic »

Add to briefcase «««34567»»»

Permissions Expand / Collapse