• (cs)

    Only been veiwing a few weeks and I get first?

  • (cs)

    Unfortunately this is so typical for SQL Server; simple enough for anyone to have a go - simple enough for anyone to f#{[ up!

    Add this to the simplicity of ASP.net and you have a recipe for disaster - just add an idiot and stir occasionally.

  • Fist! (unregistered) in reply to Martin
    Martin:
    Only been veiwing a few weeks and I get first?


    Naw, the rest of us read it and try to say something meaningful...
  • Whiskey Tango Foxtrot? Over. (unregistered)

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

  • Whiskey Tango Foxtrot? Over. (unregistered) in reply to Fist!

    Fist:
    Martin:
    Only been veiwing a few weeks and I get first?


    Naw, the rest of us read it and try to say something meaningful...

    Except for yourself, you mean. ;)

  • (cs) in reply to Whiskey Tango Foxtrot? Over.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    Errors. I don't believe that curly braces are used anywhere in SQL. He was probably trying to do a nested query using curlies instead of parens.

  • Fist! (unregistered) in reply to Whiskey Tango Foxtrot? Over.
    Anonymous:

    Fist:
    Martin:
    Only been veiwing a few weeks and I get first?


    Naw, the rest of us read it and try to say something meaningful...

    Except for yourself, you mean. ;)



    Yes, and any subsequent replies. ;) ;)
  • (cs) in reply to Whiskey Tango Foxtrot? Over.
    Anonymous:

    Fist:
    Martin:
    Only been veiwing a few weeks and I get first?


    Naw, the rest of us read it and try to say something meaningful...

    Except for yourself, you mean. ;)

     

    Just trying to join the same club as everyone else who claims first [:P]

    Anyway; got over excited and pressed post before actually typing the real message [B]

  • (cs) in reply to Whiskey Tango Foxtrot? Over.
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]

  • AnonyMouse (unregistered) in reply to Whiskey Tango Foxtrot? Over.

    It just does not work.

    I am guessing a sql function call was the hangup, or a table creation script.

    create table SomeTable(a int, b int) <- works create table sometable{a int, b int} <- does not work

  • ChiefCrazyTalk (unregistered) in reply to Volmarias

    Volmarias:
    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not? Errors. I don't believe that curly braces are used anywhere in SQL. He was probably trying to do a nested query using curlies instead of parens.

     

    So...the real WTF is that he was using curly braces in a SQL Statement.  The rest of the story leading up to that really has no bearing on anything.  Except why WAS he selecting Top 5?  Hard to guess without the context.  Probably just showing 5 records per screen, I assume.

  • (cs) in reply to Whiskey Tango Foxtrot? Over.
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.
  • (cs) in reply to Martin

    Martin:
    Only been veiwing a few weeks and I get first?

    It's not based on seniority.[;)]

    What strikes me about the above story is how careful everyone is not to just laugh in the guys face. In most forums for IT pros that I've seen (even here, sometimes), IT geeks are not shy about pointing out a colleague's mistakes! [:D]

  • (cs) in reply to Manni
    Manni:
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]



    We should all program in LISP, where parenthesis are all you need.
  • (cs) in reply to R.Flowers
    R.Flowers:

    What strikes me about the above story is how careful everyone is not to just laugh in the guys face. In most forums for IT pros that I've seen (even here, sometimes), IT geeks are not shy about pointing out a colleague's mistakes! [:D]

     

    Shy about it; we have a big cowboy hat in the office that is cermoniously placed on the offenders head!

  • Fist! (unregistered) in reply to Manni
    Manni:
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]


    No... What we don't get is why using braces would create a "TOP 5" ah-ha that using parenthesis wouldn't.  Also, I have used a language where you can use parens, brackets, braces, etc, as you choose, to help with visual matching of delimeters (they all function the same).  So yes, sometimes you can expect such things to work, especially if you have done enough programming to be familiar with such languages.
  • (cs) in reply to Whiskey Tango Foxtrot? Over.

    Anonymous:
    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    Well, when you use curly braces (also known as pointy parentheses), then you're saying that not only will you accept the values inside the braces, but also the ones just to the left and right of those values. So (2) would just be 2, but {2} would be "something kinda close to 2". It's like parentheses with very small greater than and less than signs attached to them.

    [;)]

  • (cs)

    Here is a rule of thumb. If you're at the point of blaming someone else for your code not working get up and take walk; it is you , not them...

  • IanB (unregistered) in reply to AnonyMouse

    I think the point is he was claiming to be some kind of hardcore, full-on, seen-it-all experienced legend in SQL and ASP.Net when, in fact, not knowing "TOP" is a valid (and useful) SQL keyword means he is a total n00b. 

    Plus, his SQL code must be horrific - not correctly using parentheses for anything other than some very simple SQL statements is admirably rubbish.

    I wonder if he knows about views, stored procedures, SQL injection.....

     

  • (cs) in reply to John Smallberries
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

  • Joe (unregistered) in reply to Manni

    In Foxpro foo(a, b) = foo[a, b] if foo is an array

  • (cs) in reply to Otto
    Otto:

    Anonymous:
    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    Well, when you use curly braces (also known as pointy parentheses), then you're saying that not only will you accept the values inside the braces, but also the ones just to the left and right of those values. So (2) would just be 2, but {2} would be "something kinda close to 2". It's like parentheses with very small greater than and less than signs attached to them.

    [;)]

     

    Just tried that ...

    <FONT color=#0000ff size=2>

    select</FONT><FONT size=2> </FONT><FONT color=#808080 size=2>*</FONT><FONT size=2> </FONT><FONT color=#0000ff size=2>from</FONT><FONT size=2> category

    </FONT><FONT color=#0000ff size=2>

    where</FONT><FONT size=2> iCategoryId </FONT><FONT color=#808080 size=2>=</FONT><FONT size=2> </FONT><FONT color=#808080 size=2>{</FONT><FONT size=2>34</FONT><FONT color=#808080 size=2>}</FONT>

    Result ...

    <FONT size=1>

    <FONT color=#ff0000>Msg 102, Level 15, State 1, Line 2</FONT>

    <FONT color=#ff0000>Incorrect syntax near '34'.</FONT>

    </FONT><FONT color=#808080 size=2><FONT size=1></FONT></FONT>
  • (cs) in reply to Fist!
    Fist:
    Manni:
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]


    No... What we don't get is why using braces would create a "TOP 5" ah-ha that using parenthesis wouldn't.  Also, I have used a language where you can use parens, brackets, braces, etc, as you choose, to help with visual matching of delimeters (they all function the same).  So yes, sometimes you can expect such things to work, especially if you have done enough programming to be familiar with such languages.

    A surefire way to bring out the naysayers is to declare that something isn't possible. Yes I'm sure such a language exists that gives you the power to pick and choose, but is it one of the major languages like C#, C++, VB6/VB.Net/ASP/ASP.Net, SQL, Perl, PHP?

    Next time try focusing on the actual article rather than proving other people's comments wrong. You would have noticed that there was no correlation between the "top 5" statement and the curly braces. The idiot programmer tried to blame the problem on a SQL statement he'd never seen before, but instead the problem was elsewhere in his code where he tried to use curly braces incorrectly.

  • (cs) in reply to Manni
    Manni:
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]

    I always use:

    #DEFINE LEFT_DELIMETER (
    #DEFINE RIGHT_DELIMETER )

    This is handy for 2 reasons. First, it saves confusion, since { looks so much like (. Second, my code is very easy to maintain in case the definition of parenthesis changes.*

    * (another lame joke, in case it's too dry)

  • tdog (unregistered) in reply to Martin
    Martin:

    Unfortunately this is so typical for SQL Server; simple enough for anyone to have a go - simple enough for anyone to f#{[ up!

    Add this to the simplicity of ASP.net and you have a recipe for disaster - just add an idiot and stir occasionally.

     

    BOSH (except for the idiot part) !

    This WTF is all about methodology (and over confident morons of course), not technology.  Database interactivity should always be tested independent from code.  Viva stored procs!<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    -- tdog<o:p></o:p>

     

  • (cs) in reply to R.Flowers
    R.Flowers:
    Manni:
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]

    I always use:

    #DEFINE LEFT_DELIMETER (
    #DEFINE RIGHT_DELIMETER )

    This is handy for 2 reasons. First, it saves confusion, since { looks so much like (. Second, my code is very easy to maintain in case the definition of parenthesis changes.*

    * (another lame joke, in case it's too dry)

    My solution: only use languages that don't support parenthesis. Screw your functions, I'll just copy-paste. I don't need your stinking arrays, I'll just make 3200 variables.

  • (cs)
    Alex Papadimoulis:
    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.
    Of course, we're all brillant, but it would still may have been interesting to see a snippet of the actual offending code.  The 'top 5' comment by the youngster was a good teaser as to what the real WTF must look like.
  • (cs) in reply to Fist!

    > No... What we don't get is why using braces
    > would create a "TOP 5" ah-ha that using
    > parenthesis [sic] wouldn't.

    From http://www.craigsmullins.com/ssu_0900.htm:


    Using the TOP Key Word

    Using ROWCOUNT, however, probably is not the best solution. It requires multiple commands and might be confusing. Instead, you should consider using another Transact-SQL extension, the TOP key word. The TOP key word is specified right in the SELECT statement. Its primary benefit is that it is including in the SQL code of the query and will not impact any other subsequent queries.

    The TOP Transact-SQL feature can be used as follows:

    SELECT TOP 10 TITLE, PRICE

    FROM TITLES

    ORDER BY PRICE DESC

    Of course, the TOP value can be any number, not just 10. For example, to return the only the top five highest-priced titles simply change the query as follows:

    SELECT TOP 5 TITLE, PRICE
    FROM TITLES

    ORDER BY PRICE DESC

    This is probably the simplest and most elegant solution for limiting the number of rows returned by a SQL Server query.

  • (cs) in reply to Digitalbath
    Digitalbath:
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

    If APPDOC_NUM was the PK then there would be only one record in that table with the APPDOC_NUM of 88712, the Query will only return one record ever and TOP 5 is a useless addition to the query. However if APPDOC_NUM Isn't the PK but a FK or a Non-Unique key then there would be a bunch of results and you would be pulling only the top 5, but that would be in whatever order they are stored in the Table itself, not random.

    The curly braces/parenthesis bit is the actual problem, not the top 5 thing.

    Erik of Ekedahl

  • (cs) in reply to chaim79
    chaim79:
    Digitalbath:
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

    If APPDOC_NUM was the PK then there would be only one record in that table with the APPDOC_NUM of 88712, the Query will only return one record ever and TOP 5 is a useless addition to the query. However if APPDOC_NUM Isn't the PK but a FK or a Non-Unique key then there would be a bunch of results and you would be pulling only the top 5, but that would be in whatever order they are stored in the Table itself, not random.

    The curly braces/parenthesis bit is the actual problem, not the top 5 thing.

    Erik of Ekedahl

    Oh, right...sorry.  In my haste to make my first post ever, I didn't read the post close enough...I was thinking FK.  Oops.

  • (cs) in reply to efox
    efox:

    Here is a rule of thumb. If you're at the point of blaming someone else for your code not working get up and take walk; it is you , not them...

    More often than not, by the time I get to the point of suspecting someone else's code I turn out to be right. I'm not always right, but in general, the more sure I am, the more likely I am to be right on this matter. It's a matter of experience.

    So, I'm not sure if there's a general rule of thumb here that can be applied. The guy in the story sure thought he had a lot of experience. But if he was using braces in SQL statements, he obviously hadn't had as much as he thought he had.

  • (cs) in reply to R.Flowers
    R.Flowers:
    Manni:
    Whiskey Tango Foxtrot:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    foo(a, b) <> foo[a, b]

    I always use:

    #DEFINE LEFT_DELIMETER (
    #DEFINE RIGHT_DELIMETER )

    This is handy for 2 reasons. First, it saves confusion, since { looks so much like (. Second, my code is very easy to maintain in case the definition of parenthesis changes.*

    * (another lame joke, in case it's too dry)



    You forgot to use the constant in your post. It should have been:

    * LEFT_DELIMITER another lame joke, in case it's too dry RIGHT_DELIMITER
  • (cs)

    I bet in the real story it wasn't a young programmer, it was a highly paid consultant!

  • Scott B. (unregistered) in reply to Digitalbath
    Digitalbath:
    chaim79:
    Digitalbath:
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

    If APPDOC_NUM was the PK then there would be only one record in that table with the APPDOC_NUM of 88712, the Query will only return one record ever and TOP 5 is a useless addition to the query. However if APPDOC_NUM Isn't the PK but a FK or a Non-Unique key then there would be a bunch of results and you would be pulling only the top 5, but that would be in whatever order they are stored in the Table itself, not random.

    The curly braces/parenthesis bit is the actual problem, not the top 5 thing.

    Erik of Ekedahl

    Oh, right...sorry.  In my haste to make my first post ever, I didn't read the post close enough...I was thinking FK.  Oops.


    Pretty neat 3D pyramid we're building here.
  • Whiskey Tango Foxtrot? Over. (unregistered) in reply to Manni

    Manni:
    Fist:
    No... What we don't get is why using braces would create a "TOP 5" ah-ha that using parenthesis wouldn't.  Also, I have used a language where you can use parens, brackets, braces, etc, as you choose, to help with visual matching of delimeters (they all function the same).  So yes, sometimes you can expect such things to work, especially if you have done enough programming to be familiar with such languages.
    The idiot programmer tried to blame the problem on a SQL statement he'd never seen before, but instead the problem was elsewhere in his code where he tried to use curly braces incorrectly.

    What I didn't get was exactly as Fist presented it: how do curly braces cause the insertion of a TOP 5? Now, I understand that the WTF may be that the curly braces did not insert a TOP 5, but that they created invalid SQL statements, thus showing that the programmer is overly-arrogant *and* idiotic.

    I know Structured Query Language, but had never heard of curly braces in SQL. I thought perhaps it was something to do with the .NET String.Format syntax, which uses curly braces for formatted string insertions. And yes, I have indeed programmed quite a bit (although usually PHP/MySQL when it comes to the web) and know the difference between braces and parens and their use in most programming languages. I was thrown off by the arrogant programmer's proclaimation that the TOP 5 was the cause of the error.

  • LizardFoot (unregistered)
    Alex Papadimoulis:
    <font color="#000099">SELECT TOP</font> 5 RCRD_CD, OWNR_ID
    <font color="#000099">FROM</font> DLX_APPLICATION_DOCS
    <font color="#000099">WHERE</font> APPDOC_NUM = <font color="#000000">'88712'</font>


    Okay... APPDOC_NUM is a string value?  Brillant!!


  • (cs) in reply to Scott B.
    Anonymous:
    Digitalbath:
    chaim79:
    Digitalbath:
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

    If APPDOC_NUM was the PK then there would be only one record in that table with the APPDOC_NUM of 88712, the Query will only return one record ever and TOP 5 is a useless addition to the query. However if APPDOC_NUM Isn't the PK but a FK or a Non-Unique key then there would be a bunch of results and you would be pulling only the top 5, but that would be in whatever order they are stored in the Table itself, not random.

    The curly braces/parenthesis bit is the actual problem, not the top 5 thing.

    Erik of Ekedahl

    Oh, right...sorry.  In my haste to make my first post ever, I didn't read the post close enough...I was thinking FK.  Oops.


    Pretty neat 3D pyramid we're building here.

    If you look at it long enough and cross your eyes, you see Jesus. Or a duck.

  • Cliff (unregistered) in reply to Manni
    Manni:
    [

    I don't think you do much programming at all if you think you can switch out parenthesis for another delimiter and expect the code to work the same.

    So what is the difference between $x =~ s(this)(that)  and $x =~ s{this}{that} ?
  • Whiskey Tango Foxtrot? Over. (unregistered) in reply to LizardFoot
    Anonymous:
    Alex Papadimoulis:
    <FONT color=#000099>SELECT TOP</FONT> 5 RCRD_CD, OWNR_ID
    <FONT color=#000099>FROM</FONT> DLX_APPLICATION_DOCS
    <FONT color=#000099>WHERE</FONT> APPDOC_NUM = <FONT color=#000000>'88712'</FONT>



    Okay... APPDOC_NUM is a string value?  Brillant!!


    Having a "number" that's actually a string data type is amazingly common in databases, especially older ones.

  • Anonymous (unregistered) in reply to Martin

    Wooooooshhhhhhhhhh.........

  • jkaiser (unregistered) in reply to Manni
    Manni:
    Anonymous:
    Digitalbath:
    chaim79:
    Digitalbath:
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

    If APPDOC_NUM was the PK then there would be only one record in that table with the APPDOC_NUM of 88712, the Query will only return one record ever and TOP 5 is a useless addition to the query. However if APPDOC_NUM Isn't the PK but a FK or a Non-Unique key then there would be a bunch of results and you would be pulling only the top 5, but that would be in whatever order they are stored in the Table itself, not random.

    The curly braces/parenthesis bit is the actual problem, not the top 5 thing.

    Erik of Ekedahl

    Oh, right...sorry.  In my haste to make my first post ever, I didn't read the post close enough...I was thinking FK.  Oops.


    Pretty neat 3D pyramid we're building here.

    If you look at it long enough and cross your eyes, you see Jesus. Or a duck.



    It look more like a ziggurat to me.......
  • (cs) in reply to Manni
    Manni:
    Anonymous:
    Digitalbath:
    chaim79:
    Digitalbath:
    John Smallberries:
    Anonymous:

    The systems guy pointed out the problem right away: you shouldn't be using curly braces within your SQL queries like that; you need to use regular parenthesis.

    I'll admit, I don't do much ASP.NET/SQL Server programming. What does using curly braces cause that using parenthesis does not?


    I do a lot of SQL/ASP.Net and I'm not sure either. I'm  pretty sure they don't mean "top 5".

    Also, it looks like APPDOC_NUM would be the PK, so "top" wouldn't do anything anyway.

    If APPDOC_NUM was the PK, wouldn't that query just return 5 results (assuming there was at least 5) that had the APPDOC_NUM of 88712?  It looks like if you were doing that (for whatever reason) you would need an order by so you just didn't get some random 5 results returned...

    If APPDOC_NUM was the PK then there would be only one record in that table with the APPDOC_NUM of 88712, the Query will only return one record ever and TOP 5 is a useless addition to the query. However if APPDOC_NUM Isn't the PK but a FK or a Non-Unique key then there would be a bunch of results and you would be pulling only the top 5, but that would be in whatever order they are stored in the Table itself, not random.

    The curly braces/parenthesis bit is the actual problem, not the top 5 thing.

    Erik of Ekedahl

    Oh, right...sorry.  In my haste to make my first post ever, I didn't read the post close enough...I was thinking FK.  Oops.


    Pretty neat 3D pyramid we're building here.

    If you look at it long enough and cross your eyes, you see Jesus. Or a duck.

    I am offended by your comparison of Jesus to a duck. I fully intend to riot and burn something down. Or take a nap, I can't decide...

  • (cs)

    "

    Look -- select *top five* record code -- I've never seen *top five* before, that must be it! Your logging tools must be adding that in there, causing the app to crash. "

    The other WTF is that he believed (or ever thought others would believe) LOGGING tools could INJECT additional parameters into a SQL command string!

     

     

  • (cs) in reply to Omnifarious

    OK, not a rule of thumb but sometimes the thumbs rule.

    What I'm getting at is never to rule yourself out as the source of an error. The guy didn't just fail as a result of his ignorance but because of his inflated opinion of himself, that's the true WTF.

  • diaphanein (unregistered) in reply to Omnifarious
    Omnifarious:

    More often than not, by the time I get to the point of suspecting someone else's code I turn out to be right. I'm not always right, but in general, the more sure I am, the more likely I am to be right on this matter. It's a matter of experience.

    Generally, I'm the same.  I once had a 6-month period where at least once or twice a month, I had filed bugs and had them confirmed against various IBM DB2/UDB/DB2 Connect software.  I also had another three-week debugging experience getting DB2 BLOBs to work in a classic ASP app (before the days of .Net).  A week of that was spent on three-way conference calls with techs from MS and IBM trying to figure out why I had twice number of bytes in the database as I fed into ADO and every other byte was null.  Can blame that one on unicode and VBS weak typing.  (byte-data -> unicode strings...bad).  That last one was my "fault", but it took all three of us a week to figure out all of the how/what/why/workaround of the problem.

  • (cs) in reply to Manni

    Manni:

    If you look at it long enough and cross your eyes, you see Jesus. Or a duck.

    I see Ted Nugent.

  • (cs) in reply to Omnifarious
    Omnifarious:
    efox:

    Here is a rule of thumb. If you're at the point of blaming someone else for your code not working get up and take walk; it is you , not them...

    More often than not, by the time I get to the point of suspecting someone else's code I turn out to be right. I'm not always right, but in general, the more sure I am, the more likely I am to be right on this matter. It's a matter of experience.

    So, I'm not sure if there's a general rule of thumb here that can be applied. The guy in the story sure thought he had a lot of experience. But if he was using braces in SQL statements, he obviously hadn't had as much as he thought he had.


    OK, not a rule of thumb but sometimes the thumbs rule. What I'm getting at is never to rule yourself out as the source of an error. The guy didn't just fail as a result of his ignorance but because of his inflated opinion of himself, that's the true WTF.


  • Krenn (unregistered) in reply to Fist!
    Fist:
    No... What we don't get is why using braces would create a "TOP 5" ah-ha that using parenthesis wouldn't.  Also, I have used a language where you can use parens, brackets, braces, etc, as you choose, to help with visual matching of delimeters (they all function the same).  So yes, sometimes you can expect such things to work, especially if you have done enough programming to be familiar with such languages.

    The "TOP 5" wasn't created by the curly braces.  It's simply an indicator of how little the know-it-all knows about SQL, that he's unfamiliar with such a basic limit clause.  The reason it's there is to set the stage, to show it's ignorance rather than a typo that lead to the use of {} instead of ().
  • (cs) in reply to Whiskey Tango Foxtrot? Over.

    In SQL SERVER (at least 2005) numbers can optionally be inside single quotes.

    I have confirmed this because I am running SQL SERVER 2005. So something like this is valid:

    SELECT * FROM users WHERE id>'0'

  • Anonymous Coward (unregistered) in reply to LizardFoot
    Anonymous:
    Alex Papadimoulis:
    <font color="#000099">SELECT TOP</font> 5 RCRD_CD, OWNR_ID
    <font color="#000099">FROM</font> DLX_APPLICATION_DOCS
    <font color="#000099">WHERE</font> APPDOC_NUM = <font color="#000000">'88712'</font>


    Okay... APPDOC_NUM is a string value?  Brillant!!




    Document numbers frequently have letters and dashes in them.  The problem is the people who insist on calling them document numbers, not the smart DB designer who stores them in a string.

    Other numbers that are not numbers include SSN, ISBN, etc.

Leave a comment on “Obviously The Problem”

Log In or post as a guest

Replying to comment #:

« Return to Article