• ChiefCrazyTalk (unregistered) in reply to Whiskey Tango Foxtrot? Over.
    Anonymous:
    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.

     

    Agreed - not a WTF at all.  For all we know, "88712A" is a valid appdoc_num.

  • (cs) in reply to frito
    frito:
    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'


    I give up. I can't begin to imagine why they thought that was a good idea. Nothing like taking a language that even relatively good programmers don't understand well, making some absurd, useless, syntactical change and making the change even more confusing to read/maintain than the original was.

    I challenge someone to give me a good justification for that nonsense. (I'm sure that are several justifications, but I'm looking for a GOOD one. )
  • (cs) in reply to WTF Batman

    WTF Batman:
    frito:
    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'


    I give up. I can't begin to imagine why they thought that was a good idea. Nothing like taking a language that even relatively good programmers don't understand well, making some absurd, useless, syntactical change and making the change even more confusing to read/maintain than the original was.

    I challenge someone to give me a good justification for that nonsense. (I'm sure that are several justifications, but I'm looking for a GOOD one. )

    Implicit conversions so all those VB programmers will have an easy transition when learning how to royally destroy a SQL database.

  • clueless (unregistered)

    I think the { were for the .net string.format statements:

    string.Format("SELECT TOP {0} * FROM Table", 5) == "SELECT TOP 5 * FROM Table"


  • (cs) in reply to Manni
    Manni:

    WTF Batman:
    frito:
    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'


    I give up. I can't begin to imagine why they thought that was a good idea. Nothing like taking a language that even relatively good programmers don't understand well, making some absurd, useless, syntactical change and making the change even more confusing to read/maintain than the original was.

    I challenge someone to give me a good justification for that nonsense. (I'm sure that are several justifications, but I'm looking for a GOOD one. )

    Implicit conversions so all those VB programmers will have an easy transition when learning how to royally destroy a SQL database.



    Sadly, I think you're correct. If code won't even run on another database because some idjit's VB app uses implicit conversion all over the place, they're less apt to switch to Sybase or anything else that runs T-SQL. Not that they really could anyway, if they were using user-defined functions, TOP, or all those other neat extensions.

    The difference is that I wish Sybase would pick up some of those extensions. This one is just stupid.

    // livin' in Sybase world.

  • John Hensley (unregistered) in reply to Krenn
    Anonymous:

    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 ().

    Exactly. This wouldn't be nearly as WTF if it didn't mention how full of himself the kid was.

  • anonymouse (unregistered)

    You can use curly braces in odbc sql. It's used for date conversion functions etc. For example :

    select * from tableBlat where dateTimeColumn > {d '1999-10-02'}

  • Adam C (unregistered) in reply to R.Flowers
    R.Flowers:

    Manni:

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

    I see Ted Nugent.



    Did Ted shoot Jesus or the duck?
  • diaphanein (unregistered) in reply to frito

    frito:
    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'

    You can, but I wouldn't recommend it.  What's probably happenning here is that id is being implicitly converted to a string for the comparison.  So, you might if you queried for '100', you might find yourself being returned id 99 unexpectedly.  I've not confirmed this, but consider yourself warned.

  • your mama (unregistered) in reply to diaphanein
    Anonymous:

    frito:
    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'

    You can, but I wouldn't recommend it.  What's probably happenning here is that id is being implicitly converted to a string for the comparison.  So, you might if you queried for '100', you might find yourself being returned id 99 unexpectedly.  I've not confirmed this, but consider yourself warned.

    how does 100 gets implicitly converted to 99? now THAT is a WTF. Everyone knows that 100 converts to 42.

     

  • (cs) in reply to WTF Batman

    So now when you 'ORDER BY' ints, you get the correct ...

    0

    1

    10

    3

    42

    9

    etc.... ha ha ha

  • (cs) in reply to Fist!
    Anonymous:
    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. ;) ;)


    Including this one ;-P
  • (cs) in reply to Adam C
    Anonymous:
    R.Flowers:

    Manni:

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

    I see Ted Nugent.



    Did Ted shoot Jesus or the duck?


    Ted shot the duck.  Dick Cheney would have winged Jesus.
  • Colin McGuigan (unregistered) in reply to diaphanein
    Anonymous:

    frito:
    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'

    You can, but I wouldn't recommend it.  What's probably happenning here is that id is being implicitly converted to a string for the comparison.  So, you might if you queried for '100', you might find yourself being returned id 99 unexpectedly.  I've not confirmed this, but consider yourself warned.



    Incorrect; it converts the string to an integer.  Consider the following:

    SELECT * FROM users WHERE id > 'a'

    If you were correct, that would work.  But in reality, it throws "Syntax error converting the varchar value 'a' to a column of data type int".
  • wbradney (unregistered) in reply to WTF Batman

    I believe that works in ORACLE, too. If I remember correctly from my DB days (Oracle 5?) single quotes should always work around literal operands and was in fact quite useful when building dynamic SQL queries 'the old way' (this is back when dynamic SQL meant string concatenation...) -- you could put quotes around all operands without regard to the type of the column.

    I wouldn't be surprised if ORACLE did this specifically to cater to concatenated SQL building. Thank god we now have driver abstractions and parameterized queries...

    And by the way, I don't really see this as a WTF. Just another youngster starting out who thinks his code can't possibly be the problem, and maybe a typo that wasn't spotted. Still, he'll learn do debug first, blame later after this.

  • Ribbly Screwspigot (unregistered) in reply to frito

    Excuse me, but how in the hell did SQL with CURLY BRACES make it into production code?

    At least, the only time I've had to debug while physically AT a server terminal was in a production setting...

    Maybe this kid works for one of those places that don't unit test, smoke test, or IQ test.

     

    See you in the bar,

    Ribbly

     

  • (cs) in reply to jkaiser
    Anonymous:
    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.......


    And we all know how difficult it is to give up ziggurats.

  • Ribbly Screwspigot (unregistered) in reply to gwenhwyfaer
    gwenhwyfaer:
    Anonymous:
    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.......


    And we all know how difficult it is to give up ziggurats.

    We need more lumber

  • Sam (unregistered) in reply to Manni
    Manni:

    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

     

    Yes:  Perl allows general switchouts, it's one of the reasons it's easy to create obfuscated code.

    s/this/that/;

    s,this,that,;

    s[this][that];

    It also means if you're, say, switching forward slashes,

    s{/}{\}; is the same as s/\//\\/;

     

    Also, why would we be assuming appdoc_num is the PK?  I see no real evidence it is.

  • BP (unregistered)

    Looks like a typo to me.

    ... and as we all have to eat a little humble pie now and then to remind us that no, we are not the smartest guys in the world...

    I don't think I'd call this a WTF at all... rather an example of a junior developer who will hopefull not end up on this blog in the future.

  • (cs) in reply to Manni
    Manni:
    My solution: only use languages that don't support parenthesis.


    Sooner you than me. The only one I can think of is Forth, and I wouldn't want to be embedding SQL in that... *shudder*

  • (cs) in reply to Whiskey Tango Foxtrot? Over.
    Anonymous:
    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.

    In the world of data, a number (as account number, social security number, document number) should be stored in character field; this is not an old practice but a sound maintenance practice for a handful of reasons.

    A good rule of thumb is, look at a datum (let's say, 5642157). In the context of the system, how would you say it aloud: Five-Six-Four-Two... -- or -- Five Million, Six Hundred and fourty two thousand ... ?

    If it's the former, then it's a number in the sense that most people use them -- synonymous with "identifier". If it's the latter, then you should not be calling it a number. Instead, you should use a quantifier like total, sequence, amount, percent, count, etc.

     

  • dnathe4th (unregistered) in reply to ParkinT
    ParkinT:
    "

    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!

     

     



    Agreed. :-D First post for me :-D

  • steve (unregistered) in reply to kipthegreat

    I program in scheme and speak with a lisp.  Close enough?

  • (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]



    The story says it's an older systems guy, which probably points to more maturity.  It's not a hard & fast rule, but generally your mature software engineers have moved past the dick-swinging phase of dorkdum, since it's not very productive or dignified.
  • Eric (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.



    Not SQL per se, but some ODBC stuff can go into queries.  For instance:

    select {fn now()} as currentTime

    is a valid query in SQL Server and some other dbs.


  • (cs) in reply to gwenhwyfaer

    Well, it's because the companies that make them put all that Ningirsu in them.

  • (cs) in reply to gwenhwyfaer
    gwenhwyfaer:
    Anonymous:
    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.......


    And we all know how difficult it is to give up ziggurats.

    Well, it's because the companies that make them put all that Ningirsu in them.

    preview?

  • (cs) in reply to BP
    Anonymous:
    Looks like a typo to me.

    ... and as we all have to eat a little humble pie now and then to remind us that no, we are not *the* smartest guys in the world...

    I don't think I'd call this a WTF at all... rather an example of a junior developer who will hopefull not end up on this blog in the future.


    Fine, shit happens.
    The WTF is that:
    1. The SQL was not in a stored proc (which the parser would have barfed on) so you would find the problem at development time
    2. It was not unit tested, integration tested or system tested. And we're not talking corner cases here, it only had to be executed in some way (so you would find the problem at QA time)
    3. The app had such poor exception handling/logging/tracing that a simple SQL syntax error was that hard to track down. I mean c'mon...something at the database level fails and you don't have a stack trace? (so you could find the problem at run time)
     Shameful.
  • (cs) in reply to frito
    frito:
    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'


    It's valid, but are you sure there is not a cast going on there?
    From support.microsoft.com:


    In SQL Server versions 7.0 and earlier, whenever a query uses a comparison operator between a column and a literal, the data type of the column is used regardless of the precedence rules. That is, if the column and the literal have different data types, the latter is always converted to the data type of the column (as long as the conversion is valid). This behavior may lead to undesired precision reduction, string truncation, or other conversions.

    In SQL Server 2000, this is no longer true. A conversion is performed according to data type precedence, as it is in any other comparison. In the case where a literal is positioned higher in the hierarchy, the comparison is made between the constant and the converted column (as opposed to previous versions) and therefore, results may differ. Consequently, existing indexes may not be useful, different execution plans may be chosen, and performance may be impacted negatively.

    Note If you are using SQL Server 2005, the discussion about SQL Server 2000 also applies to SQL Server 2005. For all installations of SQL Server 2005, the default compatibility level is 90.
  • Anonymous (unregistered) in reply to Alex Papadimoulis
    Alex Papadimoulis:
    Anonymous:
    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.

    In the world of data, a number (as account number, social security number, document number) should be stored in character field; this is not an old practice but a sound maintenance practice for a handful of reasons.

    A good rule of thumb is, look at a datum (let's say, 5642157). In the context of the system, how would you say it aloud: Five-Six-Four-Two... -- or -- Five Million, Six Hundred and fourty two thousand ... ?

    If it's the former, then it's a number in the sense that most people use them -- synonymous with "identifier". If it's the latter, then you should not be calling it a number. Instead, you should use a quantifier like total, sequence, amount, percent, count, etc.

     



    If you think of the database's role as storing strings of characters, then it would make sense to be able to say "... SET SocialSecurityNumber = '123456' ...", even if it *is* an integer column type.  The fact that a column is an integer column does not mean "don't accept strings of characters", it means (1) sort the values numerically rather than alphabetically (2) store a 10-digit number as a binary number to save storage space and improve performance drastically and (3) only allow numerical characters (a side-effect of the storage requirements)
  • utunga (unregistered) in reply to Omnifarious

    Beep... wrong.

    The wise programmer *always* checks his/her own code first and when they suspect a problem in other parts of the system, is always very careful about how they express this.

    In my experience a good programmer eschews the whole "my code", "their code" thing and concentrates on statements like "I think the problem may be in this bit of [implicitly, 'our'] code here".

    If you are still talking about " by the time I get to the point of suspecting someone else's code I turn out to be right." then you still ain't getting it buddy. Either youre not yet as experienced as you might want to be or you are a slow learner.

    I'll never forget the lessons that I learnt as a junior from hanging out with true coding gurus who *all* took this approach. I try to take that approach as much as possible now. Its really the best way to get things done.

    If you are even consciously thinking about whether this is 'my' or 'their' code then you are not approaching the problem right.

  • (cs) in reply to Pope
    Pope:
    gwenhwyfaer:
    Anonymous:
    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.......


    And we all know how difficult it is to give up ziggurats.

    Well, it's because the companies that make them put all that Ningirsu in them.

    preview?

    Can we stop quoting? This is starting to hypnotize me... [:O]

  • Maquis (unregistered) in reply to for(;;);

    >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.

    It's elegant, except that, in my experience, it's not fully portable.  I originally learned SQL while interning for a company that rar SQL Server.  Since then, I've done some work on home servers with both mysql and postgresql, and I recall the first time I discovered that mysql choked when I used "top 5" in a query.  Perhaps mysql is just stupid, but it's really too bad that this method of selecting isn't accepted everywhere...

  • Rain Dog (unregistered) in reply to Joe

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


    Yeah, but foxpro isn't a programming language. Duh!
  • yadda (unregistered) in reply to frito

    That is ok because of implicit conversion which eventually will jump up and get you. Very bad form.

  • (cs) in reply to Maquis
    Anonymous:

    >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.

    It's elegant, except that, in my experience, it's not fully portable.  I originally learned SQL while interning for a company that rar SQL Server.  Since then, I've done some work on home servers with both mysql and postgresql, and I recall the first time I discovered that mysql choked when I used "top 5" in a query.  Perhaps mysql is just stupid, but it's really too bad that this method of selecting isn't accepted everywhere...

    You've got to pick technology somewhere.  You can't have everything portable to every platform without making compromises.  In my experience, making SQL portable across more than a very few SQL platforms will severely limit your options.  Look at the patterns for assigning a surrogate key value.  Oracle uses a sequence that you must manually pull and insert into the table.  MS SQL makes you insert no value and use one of several functions/variables to get the assigned value.  The only portable option is to roll your own solution which will either take a bunch of work or introduce a serious locking hotspot (or a very difficult to find intermittent duplicate key problem).  The best choice is to write custom tuned SQL for each platform.  That way you can take the best advantage of each product.  That's why they make Data Layers anyways.  I tell everyone I work with that any SQL in UI code will go back for a re-write.

  • (cs) in reply to Disgruntled DBA
    Disgruntled DBA:
    Anonymous:
    R.Flowers:

    I see Ted Nugent.



    Did Ted shoot Jesus or the duck?


    Ted shot the duck.  Dick Cheney would have winged Jesus.
    Correction: Dick Cheney would have peppered Jesus.
  • (cs) in reply to utunga
    Anonymous:
    If you are even consciously thinking about whether this is 'my' or 'their' code then you are not approaching the problem right.


    You were doing fine until this point.  My code is much easier for me to check.  It is usually at hand.  OPC may not be available at all.  Being lazy^Weconomical of my time, I prefer to check first what can be easily checked if it is reasonable that it might be in error.  Sometimes, it may make more sense to check OPC first.  (Consider the case of the author being a rookie or OPC is alpha or beta.)

    Sincerely,

    Gene Wirchenko



  • AC (unregistered)

    So, I am having a hard time with this.

    Disclaimer, im not a db guy.

    So, Did he just mistype the curly braces by accident?

    Or did he think thats how you built queries in sql? Like wouldn't the first query you ever write and test pretty much tell you that curly braces are a no no? How did he get such an inflated ego, if he didn't know basic formation?

    It would be like a java programmer mixing up parens and curly braces, you'd figure it out after "hello world!".

  • Runtime Error (unregistered) in reply to triso
    triso:
    Disgruntled DBA:
    Anonymous:
    R.Flowers:

    I see Ted Nugent.



    Did Ted shoot Jesus or the duck?


    Ted shot the duck.  Dick Cheney would have winged Jesus.
    Correction: Dick Cheney would have peppered Jesus.


    Actually you need to think about it for a minute.  Jesus was a long haired middle eastern hippy guy with radical politics who spoke Aramaic.  Cheney would have peppered him and had him sent to Guantamino for further questioning
  • toxik (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    Sincerely,

    Gene Wirchenko


    I love you

  • Kiss me, I'm Polish (unregistered) in reply to Runtime Error
    Anonymous:
    triso:
    Disgruntled DBA:
    Anonymous:
    R.Flowers:

    I see Ted Nugent.



    Did Ted shoot Jesus or the duck?


    Ted shot the duck.  Dick Cheney would have winged Jesus.
    Correction: Dick Cheney would have peppered Jesus.


    Actually you need to think about it for a minute.  Jesus was a long haired middle eastern hippy guy with radical politics who spoke Aramaic.  Cheney would have peppered him and had him sent to Guantamino for further questioning
    That's because they all look the same in Zanzibar.You can't tell whether you deal with a simple terrorist or a complex terrorist.
  • (cs) in reply to Fist!
    Anonymous:
    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.


    Is that language Arithmetic?
  • Golfdan (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    My code is much easier for me to check.  It is usually at hand.  OPC may not be available at all.  Being lazy^Weconomical of my time, I prefer to check first what can be easily checked if it is reasonable that it might be in error.  Sometimes, it may make more sense to check OPC first.  (Consider the case of the author being a rookie or OPC is alpha or beta.)

    Sincerely,

    Gene Wirchenko



    What does the Orthodox Presbyterian Church (http://www.opc.org) have to do with this? Actually, scratch that. What the hell are you talking about?

  • Golfdan (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    My code is much easier for me to check.  It is usually at hand.  OPC may not be available at all.  Being lazy^Weconomical of my time, I prefer to check first what can be easily checked if it is reasonable that it might be in error.  Sometimes, it may make more sense to check OPC first.  (Consider the case of the author being a rookie or OPC is alpha or beta.)

    Sincerely,

    Gene Wirchenko



    What does the Orthodox Presbyterian Church (http://www.opc.org) have to do with this? Actually, scratch that. What the hell are you talking about?

  • (cs) in reply to Golfdan
    Anonymous:
    Gene Wirchenko:
    My code is much easier for me to check.  It is usually at hand.  OPC may not be available at all.  Being lazy^Weconomical of my time, I prefer to check first what can be easily checked if it is reasonable that it might be in error.  Sometimes, it may make more sense to check OPC first.  (Consider the case of the author being a rookie or OPC is alpha or beta.)

    Sincerely,

    Gene Wirchenko



    What does the Orthodox Presbyterian Church (http://www.opc.org) have to do with this? Actually, scratch that. What the hell are you talking about?

    <FONT face=Georgia>I think OPC == Other People's Code.</FONT>

  • Pinguis (unregistered) in reply to gwenhwyfaer

    Manni wrote: My solution: only use languages that don't support parenthesis.

    Sooner you than me. The only one I can think of is Forth, and I wouldn't want to be embedding SQL in that... shudder


    Don't forget brainfuck and Ook!. Try embendding SQL in these ;)

  • tim (unregistered)
    "he knew that it was definitely related to the
    backend, far, far behind the depths of the database servers and into
    the bowels of the organization's infrastructure"
    I like that one. I'll see if I can use it one day.
  • (cs) in reply to frito
    frito:
    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'


    That's because MSSQL will implicitly convert between string and integral datatypes.
    If it's between single quotes then it's a string, not a number.
    Your point still stands, though - the number being in a string doesn't say anything about the datatype of the actual column.

Leave a comment on “Obviously The Problem”

Log In or post as a guest

Replying to comment #:

« Return to Article