InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 19 Jun 2013 04:53:48 GMT20http://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Jesse McLain (2/13/2009)[/b]I agree with your admonition against reinventing the wheel, as Windiff does a great job. But my original intention was to provide quantitative matching results, not necessarily the visual representation of the matching.[/quote]I've found in the past that sometimes it's necessary to reinvent the wheel to add an extra bit of functionality that a tool doesn't provide. It depends how much cost is involved.[quote]This sort of "fuzzy matching" is exactly what's involved in name/address deduplication in direct marketing.[/quote]I too have had to write routines to match and format addresses when loading data from legacy business systems into newer replacements. Since, usually, these are only going to be used over a short period, I've found that the last step often comes down to a manual/visual check. Obviously, when it's finance data, finding duplicates is much more important thatn when it's a mailshot![quote]Using the current method of capturing lines of code from the spds, we would have to parse those lines into "words" based on white space, etc. Taking the example of the SELECT you made, we would have to standardize the JOIN sequence and data nicknames, compare the metadata of the results, etc. I'm not sure I would want to go in that direction, but it's possible.[/quote]Actually, with tools like Flex and Bison it might not be too hard to build something.The metadata comparison might get quite complicated (consider re-ordered equijoins) and, of course, may still fail to identify functionally equivalent code.Mon, 16 Feb 2009 02:55:06 GMTDerek Dongrayhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxthis question really got me. Amazing question. Really good one....:)Sun, 15 Feb 2009 07:34:08 GMTAnipaulhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Derek Dongray (2/13/2009)[/b][hr]Regarding your problem of stored procedure comparison, Windiff is still available (just Google "windiff download", one of the places is [url=http://www.microsoft.com/downloads/details.aspx?FamilyID=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en]Microsoft[/url]) so I'd have just used that (and regularly do!).......Sometimes the solution is just to use a simpler tool like Windiff along with the mk.1 Eyeball as used by an experience SQL writer. :D[/quote]I agree with your admonition against reinventing the wheel, as Windiff does a great job. But my original intention was to provide quantitative matching results, not necessarily the visual representation of the matching. I imagined this as being part of a larger tool to compare databases (for example, between development, testing, and production versions of a database, or instances of independently maintained databases that began as identical copies), which would involve automatic comparisons of many objects.The more subtle differences you mentioned above make the problem even more interesting, and in my comparison of the two spds of 1000+ lines each, I found many instances of such. You're right, the complexity goes upwards from there. This sort of "fuzzy matching" is exactly what's involved in name/address deduplication in direct marketing. For example, how do we match the two addresses:Jon G. Smith100 E. Main StBaltimore, MDJ. Smyth100 East Main StreetBalt. MarylandThese sorts of problems have been tackled (in fact, I've written parsing, scoring, and matching algorithms myself to handle it). I think the SQL parser would be of similar complexity. Using the current method of capturing lines of code from the spds, we would have to parse those lines into "words" based on white space, etc. Taking the example of the SELECT you made, we would have to standardize the JOIN sequence and data nicknames, compare the metadata of the results, etc. I'm not sure I would want to go in that direction, but it's possible.Fri, 13 Feb 2009 09:34:49 GMTJesse McLainhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxRegarding your problem of stored procedure comparison, Windiff is still available (just Google "windiff download", one of the places is [url=http://www.microsoft.com/downloads/details.aspx?FamilyID=49ae8576-9bb9-4126-9761-ba8011fabf38&displaylang=en]Microsoft[/url]) so I'd have just used that (and regularly do!).Of course,if you start writing your own tool, so you can ignore comments, then you are starting on a complex path since, ideally, you need to build a complete parser to check that[code]select a,b,c from tbl[/code]is equivalent to[code]SELECT d.a , d.b , d.cFROM tbl AS d[/code]or even that[code]select a.a, b.b from a join b on a.c=b.c[/code]is the same as[code]select a.a, b.b from b join a on b.c=a.c[/code]And that's [i]before[/i] comments have been introduced!Sometimes the solution is just to use a simpler tool like Windiff along with the mk.1 Eyeball as used by an experience SQL writer. :DFri, 13 Feb 2009 04:43:29 GMTDerek Dongrayhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Jesse McLain (2/12/2009)[/b][hr]...Anyways, glad everyone seemed to like the question (maybe not getting it wrong, but in terms of learing something surprising).[/quote]Thanks Jesse McLain for this question.I surely learned something :D. But I want my developers away from writing comments like this. Comments are there to help you, not to confuse you :P.KISS is the key -> Keep It Simple Stupid. Doing so, any dba or developer can easily understand your code.D. Couturier Database Administrator & ArchitectThu, 12 Feb 2009 11:51:59 GMTDCouturierhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxThis problem originally came to mind when I started work on a tool for comparing the text from stored procedures ([url]http://jessesql.blogspot.com/2009/02/comparing-stored-procedures-part-1.html[/url]). I wanted to allow the option of omitting all comments from the comparison, which of course would require me to identify and parse out comments from the text. In my research, I came across the question of how to treat nested comments - the "order of operation" of inline versus block comments, nested blocks, etc., and that's when I came across the scenario that formed this question of the day. I have to say that I was surprised, almost to the point of shock, that commenting functioned this way.Anyways, glad everyone seemed to like the question (maybe not getting it wrong, but in terms of learing something surprising).Thu, 12 Feb 2009 11:36:27 GMTJesse McLainhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxActually that just about makes sense, based on the assumption that "--" is ignored within block commentsso in this code: [code]/*print '1'--/**/note unmatched block comment marker on this line, following an inline comment markerprint '2'*/print '3'[/code]... line 1 opens a comment blockprint '1' is within the comment block so it doesn't printon the line starting with "--" , the system ignores "--" , it then finds a complete (but empty) nested block comment ; followed by some text. The text is outside the nested comment, but INSIDE the original comment block that was started on line 1, so it does not cause an error.print '2' is still within the original comment blockthe next line ends the original comment blockand print '3' then executesThu, 12 Feb 2009 05:19:17 GMTarchie flockharthttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]archie flockhart (2/12/2009)[/b][hr]Here's an interesting combination:This code works perfectly OK ( the unmatched block comment marker causes no problems because it is part of an inline comment): [code]print '1'--/*note unmatched block comment marker on this line, following an inline comment markerprint '2'print '3'[/code]result: 1 2 3Now, suppose we are asked to disable the part of the code that prints 1 and 2 ... easy, we say :) ... just put block comment markers around it ... [code]/*print '1'--/*note unmatched block comment marker on this line, following an inline comment markerprint '2'*/print '3'[/code]result : Server: Msg 113, Level 15, State 1, Line 1Missing end comment mark '*/'.oops !My attempt to explain the behaviour is: as soon as you are withiin a BLOCK COMMENT, the system ignores all INLINE COMMENT markers. For most statements, this doesn't matter, because the statement will not be executed anyway since it is part of the BLOCK COMMENT. But START BLOCK COMMENT [b]/*[/b] or END BLOCK COMMENT [b]*/[/b] instructions which look as though they should be ignored because they follow a "--" , are actually processed, and may open a nested comment block or close the existing block or cause a syntax error.Does that sound about right ?[/quote]Yeah. But you gotta try this. You'll love it![code]/*print '1'--/**/note unmatched block comment marker on this line, following an inline comment markerprint '2'*/print '3'[/code]Thu, 12 Feb 2009 05:03:17 GMTTom Garthhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxNice feature to get trapped on migration from SQL 2000 to 2005.Thu, 12 Feb 2009 03:46:32 GMTMarcin Zawadzkihttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxHere's an interesting combination:This code works perfectly OK ( the unmatched block comment marker causes no problems because it is part of an inline comment): [code]print '1'--/*note unmatched block comment marker on this line, following an inline comment markerprint '2'print '3'[/code]result: 1 2 3Now, suppose we are asked to disable the part of the code that prints 1 and 2 ... easy, we say :) ... just put block comment markers around it ... [code]/*print '1'--/*note unmatched block comment marker on this line, following an inline comment markerprint '2'*/print '3'[/code]result : Server: Msg 113, Level 15, State 1, Line 1Missing end comment mark '*/'.oops !My attempt to explain the behaviour is: as soon as you are withiin a BLOCK COMMENT, the system ignores all INLINE COMMENT markers. For most statements, this doesn't matter, because the statement will not be executed anyway since it is part of the BLOCK COMMENT. But START BLOCK COMMENT [b]/*[/b] or END BLOCK COMMENT [b]*/[/b] instructions which look as though they should be ignored because they follow a "--" , are actually processed, and may open a nested comment block or close the existing block or cause a syntax error.Does that sound about right ?Thu, 12 Feb 2009 03:33:43 GMTarchie flockharthttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxI wrote some stuff in Perl as that was what was available on the web server. It was not that bad to write code. You start with the inmost thing. Then surround with the next layer of processing. Then surround that with the next. Etc. Very powerful. I had very intense routines in a single line of code. Nice.Now come back a couple of months later and need to make one [u]little[/u] change. :w00t: Trying to uncoil those lines to remember what they did. It's not so easy to read what you wrote. :crazy:Don't get me wrong here. Perl is fine. Many people use it and find it easy. [b][i][u]I[/u][/i][/b] did not. It's the fault of [u][i][b]me[/b][/i][/u] and not Perl.Wed, 11 Feb 2009 16:38:14 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Charles Kincaid (2/11/2009)[/b][hr]Good point. But then [code]/*Good comment not.-/**/*/[/code] does work. Does this remind you of the Perl parser?[/quote]That's not as bad as it seems when you break it out.[code]/*Good comment not.-/**/*/[/code]I've never had the pleasure of working with the Perl parser. Does it defy logic?Wed, 11 Feb 2009 15:31:24 GMTTom Garthhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Charles Kincaid (2/11/2009)[/b][hr]Let me see if I can show what is going on here and why. Lets number the lines[code](00) PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /*(01) PRINT '4' --*/(02) --/*(03) PRINT '5'(04) --*/(05) /*(06) PRINT '6'(07) --/*(08) */(09) PRINT '7'(10) --*/(11) PRINT '8'[/code]Line (00) has an inline comment starting with the double dash so 2 an 3 are in the commentSame for (01) so 4 does print just like 1.Line (02) has an inline comment so the block comment starter is [b][i]par of[/i][/b] the comment and is ignored. Same for (04) and (10).Line (03) is not in any comment and gets executed. Same goes for line (11).Line (05) starts a block comment. Lines (06) and (07) are part of the block comment.Line (08) stops the block comment.[/quote]but line 09 is NOT executed so it is still part of the commented out code....................Wed, 11 Feb 2009 15:05:30 GMTgeorge sibbaldhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxGood point. But then [code]/*Good comment not.-/**/*/[/code] does work. Does this remind you of the Perl parser?Wed, 11 Feb 2009 14:57:17 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxCharles,Regarding line (10). That is the same incorrect assumption that most of us made. Line 10 is not ignored. The [i]comment begin[/i] marker causes the parser to search from the bottom up for a [i]comment end[/i] marker, and finds it on line (10).Try this:[quote]/* Good comment.--*/[/quote]Now my question is why isn't the following just as good.[quote]/* Good comment not.--/**/[/quote]hehWed, 11 Feb 2009 13:09:07 GMTTom Garthhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxLet me see if I can show what is going on here and why. Lets number the lines[code](00) PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /*(01) PRINT '4' --*/(02) --/*(03) PRINT '5'(04) --*/(05) /*(06) PRINT '6'(07) --/*(08) */(09) PRINT '7'(10) --*/(11) PRINT '8'[/code]Line (00) has an inline comment starting with the double dash so 2 an 3 are in the commentSame for (01) so 4 does print just like 1.Line (02) has an inline comment so the block comment starter is [b][i]par of[/i][/b] the comment and is ignored. Same for (04) and (10).Line (03) is not in any comment and gets executed. Same goes for line (11).Line (05) starts a block comment. Lines (06) and (07) are part of the block comment.Line (08) stops the block comment.Wed, 11 Feb 2009 12:45:50 GMTCharles Kincaidhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxThe comments Jesse refers to above are right on point. The problem with Grasshopper's in-line comments example is that too often they get left in the code when it is placed in production. When I do code reviews (and yes, we actually do them), code with those types of comments would be rejected.Wed, 11 Feb 2009 11:58:22 GMTIrish Flyerhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxI love using inline comments. Especially when hacking complex sql.For example:with something like this, I can switch things up using simple inline commentsselect a ,b-- ,c ,dfrom taba ,tabb-- ,tabc ,tabdwhere 1=1and blah-a--and a = 9and a = 18--and a in(1,2,3,4,5)and blan-b--and blah-cand blah-dWed, 11 Feb 2009 11:45:48 GMTraymond lewhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxI got it right, but now I realize it was almost by accident. [quote][b]Irish Flyer (2/11/2009)[/b][hr]Given the inconsistancies noted, I guess it brings home the point that one should be consistant in coding. Either use the -- convention to comment a line, or use /* */ pairs for comments, but don't mix them. Consistancy is just good coding practice anyway.[/quote]Good point. I tend to use the comments differently: -- to explain what (I think) the code is doing, /* */ to take out copies of code while I'm messing with it in development or to separate queries I use for testing. Most of the code in /* */ will get taken out in production.As far as inline comments - I avoid them precisely for the reasons stated above. I do add them to large queries sometimes if I feel that parts of it need to be explained separately. Maybe I ought to exercise more caution in the future.Wed, 11 Feb 2009 11:34:01 GMTOlga Bhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Myles Sigal (2/11/2009)[/b][hr][quote]It's the best way to remember which code was in the original block.[/quote]I thought that is what version control is for?[/quote]Version control isn't needed when making temporary edits for effect.Also - version control applications are not a good fit for every shop or project. Sometimes version control is whatever you are savvy enough to remember to update.Wed, 11 Feb 2009 11:27:16 GMTTom Garthhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxHere are a couple of articles related to this thread: "Worst Practice - Bad Comments", By Andy Warren, 2003/01/23:[url]http://www.sqlservercentral.com/articles/Miscellaneous/worstpracticebadcomments/893/[/url]"The case against using single-line comments", By Cade Bryant, 2003/01/22:[url]http://www.sqlservercentral.com/scripts/30672/[/url]Wed, 11 Feb 2009 11:14:47 GMTJesse McLainhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote]It's the best way to remember which code was in the original block.[/quote]I thought that is what version control is for?Wed, 11 Feb 2009 11:08:16 GMTMyles Sigalhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Irish Flyer (2/11/2009)[/b][hr]Given the inconsistancies noted, I guess it brings home the point that one should be consistant in coding. Either use the -- convention to comment a line, or use /* */ pairs for comments, but don't mix them. Consistancy is just good coding practice anyway.[/quote]I'm pretty consistent about commenting out comment blocks (--/* and --*/). It's the best way to remember which code was in the original block.Wed, 11 Feb 2009 10:46:54 GMTTom Garthhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxWow. I didn't see that coming. AND I learned something new! And that's always a good thing. :DWed, 11 Feb 2009 10:37:39 GMTKevinC.http://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxFWIW, the [url=http://extras.sqlservercentral.com/prettifier/prettifier.aspx]Simple-Talk Code Prettifier[/url] on SQLServerCentral gets it wrong (highlights [color="blue"]PRINT [/color][color="red"]'7'[/color] as executable). SSMS (2K5 SP3) shows[font="Courier New"][size="2"][color="blue"]PRINT [/color][color="red"]'1' [/color][color="green"]-- /* ;PRINT '2' */ ;PRINT '3' /*[/color][color="blue"]PRINT [/color][color="red"]'4' [/color][color="green"]--*/--/*[/color][color="blue"]PRINT [/color][color="red"]'5'[/color][color="green"]--*//*PRINT '6'--/**/PRINT '7'--*/[/color][color="blue"]PRINT [/color][color="red"]'8'[/color][/size][/font]I tried to work it out before trying SSMS and wrongly got 1,4,5,[b]7[/b] & 8 as many others did.Wed, 11 Feb 2009 10:19:35 GMTDerek Dongrayhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxInteresting and fun. My answer was 1,4,5,7,8 --wrong. I am amazed to see so many smarties out there get it right!I checked the syntax highlighting in various tools I have:sqldbx 1,4,5,7,8oracle sql developer 1,4,5,7,8SSMS 9.00.1399.00 1,4,5,8Notepad++ 1,4,5,7,8I actually tried the equivalent in plsql. The results were 1,4,5,7,8Someone put in good some extra effort at MS to make it work like this.select 1 from dual; -- /* ;PRINT '2' */ ;PRINT '3' /*select 4 from dual; --*/--/*select 5 from dual;--*//*select 6 from dual;--/**/select 7 from dual;--*/select 8 from dual;Wed, 11 Feb 2009 10:18:58 GMTraymond lewhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxWe had an error just last week where some code was commented out, tested and successful in test environment, then copy and paste to production and it failed due to a line wrap, something like thisFROM table1 t1 -- INNER JOIN table2 t2 ON t1.id = t2.idbut wrapped like thisFROM table1 t1 -- INNER JOIN table2 t2 ON t1.id = t2.id- MylesWed, 11 Feb 2009 08:51:37 GMTMyles Sigalhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Irish Flyer (2/11/2009)[/b][hr]Given the inconsistancies noted, I guess it brings home the point that one should be consistant in coding. Either use the -- convention to comment a line, or use /* */ pairs for comments, but don't mix them. Consistancy is just good coding practice anyway.[/quote]You definitely don't want to mix commenting styles, as this QoD shows. I'm coming around to the opinion that inline comments should be avoided completely. This is especially a problem when copying-and-pasting code into some text editors - inline comments can get wrapped to the next line, causing compilation problems, whereas traditional block quoting should always work ok (this is "in line" with what happened with your initial evaluation of the code - please forgive the pun).Wed, 11 Feb 2009 08:35:16 GMTJesse McLainhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Myles Sigal (2/11/2009)[/b][hr]I agree with D. Couturier; if someone brought me code for review with comments anything close to this, I'd send it back. It's nice to know the behavior, but keep it simple.[/quote]Thanks Myles Sigal. I'm glad I'm not alone.It's the --/* ... --*/ that got me.If our developpers here would write comments like that, I'd jump up to the ceiling.D. CouturierDatabase Administrator & ArchitectWed, 11 Feb 2009 08:27:31 GMTDCouturierhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxGiven the inconsistancies noted, I guess it brings home the point that one should be consistant in coding. Either use the -- convention to comment a line, or use /* */ pairs for comments, but don't mix them. Consistancy is just good coding practice anyway.Wed, 11 Feb 2009 08:21:57 GMTIrish Flyerhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxThat's right!When I corrected the code to be PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /* PRINT '4' --*/--/*PRINT '5'--*//*PRINT '6'--/**/PRINT '7'--*/PRINT '8'the reply was 1458Wed, 11 Feb 2009 08:17:30 GMTIrish Flyerhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxdon't get this at all. I answered 1,4,5,7,8 and was amazed to get it wrong, so I have checked it using QA in 2000 SP4 and SSMS 2005 SP2, both show the print '7' as NOT greened out as a comment, but it does not print! Explain that one, the gui does not see it as a comment but it acts as one.CORRECTION - QA shoes it NOT greened out, SSMS shows it greened out, NEITHER print it!Wed, 11 Feb 2009 08:15:57 GMTgeorge sibbaldhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspx[quote][b]Irish Flyer (2/11/2009)[/b][hr]Using Studio 9.00.3042.00PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /* PRINT '4' --*/--/*PRINT '5'--*//*PRINT '6'--/**/PRINT '7'--*/PRINT '8'yields a return of:158The parser only shows PRINT '1' , PRINT '5' and PRINT '8' in blue, hte rest of the PRINT statements are Green (comments)[/quote]Hi, your code isn't quite the same as Jesse's original:PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /*PRINT '4' --*/--/*PRINT '5'--*//*PRINT '6'--/**/PRINT '7'--*/PRINT '8'Here Print '4' is on a separate line.I tried your example and my result was like yours. That line break is obviously making the difference. Good old Microsoft - keep us on our toes...Wed, 11 Feb 2009 08:12:38 GMTRussell Derrett-463756http://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxI agree with D. Couturier; if someone brought me code for review with comments anything close to this, I'd send it back. It's nice to know the behavior, but keep it simple.Wed, 11 Feb 2009 08:08:21 GMTMyles Sigalhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxUsing Studio 9.00.3042.00PRINT '1' -- /* ;PRINT '2' */ ;PRINT '3' /* PRINT '4' --*/--/*PRINT '5'--*//*PRINT '6'--/**/PRINT '7'--*/PRINT '8'yields a return of:158The parser only shows PRINT '1' , PRINT '5' and PRINT '8' in blue, the rest of the PRINT statements are Green (comments)SQL Server 2005 64-Bit on Sun 4600Wed, 11 Feb 2009 08:07:37 GMTIrish Flyerhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxI'm using Microsoft SQL Server Management Studio version 9.00.2047.00I get 1, 4, 5 and 8. Where has your 4 gone?Wed, 11 Feb 2009 08:02:02 GMTRussell Derrett-463756http://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxTO Russell,What version of management studio did you use? In studio 2005 I got 1, 5, 8. I triple checked the executed code to make sure it was the same as the problem shown.Wed, 11 Feb 2009 07:56:07 GMTIrish Flyerhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxI'm glad that everyone seemed to like the question (and surprising answer); I wondered whether people would object to the obscure nature of the problem.This scenario came up when I started investigating the comparison of lines of text between stored procedures ([url]http://jessesql.blogspot.com/2009/02/comparing-stored-procedures-part-1.html[/url]). I wanted to allow the possibility in the comparison of suppressing comments - that's when I discovered this rather odd feature of commenting.Wed, 11 Feb 2009 07:49:30 GMTJesse McLainhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxThis is really exciting question.I always had feelings that /* */ has priority on – . And construction like -- /* will lead SQL to ignore /*.I was wrong! Thank you for so useful information and good lesson. ArturWed, 11 Feb 2009 07:41:14 GMTArtur Komkovhttp://www.sqlservercentral.com/Forums/Topic654391-1181-1.aspxThis was a pretty good catch! It got me :crazy:Who the heck would use comments like that. I practice the KISS method which stands for "Keep It Simple Stupid". I use this as much as possible.D. CouturierDatabase Administrator & ArchitectWed, 11 Feb 2009 07:38:37 GMTDCouturier