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