T-SQL Fun

  • Comments posted to this topic are about the item T-SQL Fun

  • This one made me pause for a sec - i was sure there was a trick somewhere in it (an extra space, some syntax or something). But straightforward it is.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Comment removed

  • Comment removed

  • Can some one breif on the below comment in this context.

    "This is one of the reasons to rely on checking 'equality' rather than 'inequality' "

    Thanks

  • I was not confused at all. I knew the answer is 'OK'.

    But I dint understand the relevance of this question.

  • me too.

  • At the risk of looking foolish, what am I missing here?

    Is this not a case of:

    if (condition) or (condition)

    then

    else

    That's just an if-then-else statement.

    Both conditions equate to false, so you get the else branch, that's how the logic always works... I don't see a gotcha, a sneaky trick, any specific knowledge at all here?

    if (I am wrong)

    then (tell me why)

    else (agree with me)

  • I guess its because people tend to evaluate 'true' things first, especially in IF clauses.

    What we have here is a double negative, which requires more consideration and work through than

    if @var = 'e' and @C = 'i'

    then 'OK'

    else 'Not ok'

    which is much easier to evaluate as a human, and logically equivalent.

  • declare @var char, @C char

    set @C = 'I'

    set @var = 'E'

    if (ascii(@c) ascii('I')) OR (ascii(@var) ascii('E'))

    begin

    select 'not OK'

    end

    else

    select 'OK'

  • This is one of the reasons to rely on checking 'equality' rather than 'inequality'.

    I have to agree with others. What does the above quote have to do with the question? Yes, the question does deal with two inequality matches, but it's straightforward and does as expected - what is it trying to teach that we should be using an equality match for?

    Wayne
    Microsoft Certified Master: SQL Server 2008
    Author - SQL Server T-SQL Recipes


    If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
    Links:
    For better assistance in answering your questions
    Performance Problems
    Common date/time routines
    Understanding and Using APPLY Part 1 & Part 2

  • I am very confused as to why the comments stated:

    "This is one of the reasons to rely on checking 'equality' rather than 'inequality'". The result was generated as expected.

  • This is one of the reasons to rely on checking 'equality' rather than 'inequality'.

    Huh? This is just a simple compound condition test. The fact that it has an OR and "not equal to" comparison operators is immaterial.

    In reality, for a certain business case, checking for equality could be totally wrong as you would have to check for every possible value vs. just checking the ones that are not allowed.

    Perhaps it was meant to be coded as:

    [font="Courier New"]IF (@c 'I') AND (@var 'E')[/font]

    which is a common mistake when coding compound negative conditions.


    [font="Arial Narrow"](PHB) I think we should build an SQL database. (Dilbert) What color do you want that database? (PHB) I think mauve has the most RAM.[/font]

  • I thought it was a decent question - the double negative almost made me answer 'NOT OK' rather than the correct answer, 'OK'. The author was simply pointing out that there is an issue with readability when using a double negative. You can disagree, but readability is about other people being able to read your code, not necessarily your own take on it.

  • dave.farmer (9/16/2009)


    At the risk of looking foolish, what am I missing here?

    Is this not a case of:

    if (condition) or (condition)

    then

    else

    That's just an if-then-else statement.

    Both conditions equate to false, so you get the else branch, that's how the logic always works... I don't see a gotcha, a sneaky trick, any specific knowledge at all here?

    if (I am wrong)

    then (tell me why)

    else (agree with me)

    agree with me 🙂

Viewing 15 posts - 1 through 15 (of 24 total)

You must be logged in to reply to this topic. Login to reply