• (nodebb) 
    If TDWTF.HasComments.Equals(False) Then Frist = True
  • Labasta (unregistered) 
    If Labasta.HasJob.Equals(False) Then NoMoney = True
  • (nodebb)

    Shakespeare was wrong. A rose by any other name is not the same.

  • Michael R (unregistered)

    "I have come to chew bubble gum and kick ass. And I'm all out of bubble gum.". And rows apparently, or not.

  • TheCPUWizard (unregistered)

    "If anything goes wrong in this process, we don't clean up our open connection" -- wrong, read up on using statement... it is so that things will be cleaned up in the event of an exception.

  • ichbinkeinroboter (unregistered)

    "Video unavailable This video contains content from Tele München Fernseh GmbH + Co. Produktionsgesellschaft VOD, who has blocked it in your country on copyright grounds"

    I am in GERMANY!

    Streaming licensing is The Real WTF (I used to work for a firm doing tech behind streaming for some major providers. It really is)

  • Guest (unregistered)

    Well, COUNT will have to run the whole query anyway, which may or may not be slow. For slower queries, we could instead LIMIT 1, as that should stop processing early.

    But we can go deeper, as having a method like this could be a sign of even worse code. Would it be trying to see if the query has rows before running the real query? That would be a bigger WTF.

  • Not a robot (unregistered)

    You'd want to use "Return Not r.HasRows" rather than "Return r.HasRows"

  • WTFGuy (unregistered)

    @TheCPUWizard Ref

    "If anything goes wrong in this process, we don't clean up our open connection" -- wrong, read up on using statement... it is so that things will be cleaned up in the event of an exception.

    Read up on the code good Sir.

    The connection is declared, created, opened, and closed outside the Using clause. As is the SQLCommand object. That Using clause does protect the SQLDataReader and only the SQLDataReader.

  • (nodebb) in reply to Guest

    Under MS SQL indexes store the current count (and therefore also indirect tables when they have a primary key), so a count against indexes is super fast. However that is a very MS SQL specific behavior, I think all other DBs execute queries and just don't stream the result. So yes, COUNT can be fast depending on the DB - which is a excellent reason why someone should never write plain SQL statements.

  • (nodebb)

    I see this row count anti-pattern so much on Stack Overflow that I've become inured to it. It's down there with using SELECT * when you only need one or two columns.

  • (nodebb) in reply to Guest

    Even if COUNT has to run the full query logic, it doesn't have to return all the data to the client.

    The optimal way is to use SELECT EXISTS (subquery) AS any_found. This can stop as soon as it finds the first match and doesn't have to return any table contents.

  • Jaloopa (unregistered) in reply to TheCPUWizard

    "If anything goes wrong in this process, we don't clean up our open connection" -- wrong, read up on using statement... it is so that things will be cleaned up in the event of an exception.

    The SqlDataReader is correctly cleaned up if there's an exception executing the command. The SqlConnection cn is not, as using works like a try ... finally so the exception will be propagated and execution will miss the cn.Close() line

  • (nodebb) in reply to TheCPUWizard

    The data reader will be disposed, but not the connection. You need on this low level for every IDisposable object a properly scoped using; which is the SqlConnection, potentionally the SqlTransaction (which also needs to be commited or rolledback, or you have a dangling transaction no matter if you Dispose the object or not) if created, the SqlCommand and finally the SqlDataReader.

  • Duke of New York (unregistered)

    rs is a result set? a reader source? a collection of rows or records? Of course not. It's a command.

  • Oracles (unregistered)

    "Nothing is true" is surely a statement about the human condition.

  • Duke of New York (unregistered)

    TDWTF: an all-you-can-eat trash can of programmer confusion

  • t (unregistered)

    Reminds me of NaDa, the guaranteed bug free software. Because it didn't do anything!

  • Officer Johnny Holzkopf (unregistered) in reply to t

    Even programs that don't do anything can contain bugs: https://catless.ncl.ac.uk/Risks/6/14#subj2

  • (nodebb) in reply to Not a robot

    Erm...either way, looks like that leaves connection cn open, unless the connection IS wrapped in a Using

  • (nodebb)

    @MaxiTB ref

    which is the SqlConnection, potentionally the SqlTransaction (which also needs to be commited or rolledback, or you have a dangling transaction no matter if you Dispose the object or not) if created, the SqlCommand and finally the SqlDataReader.

    Agree completely with your overarching point, but SQLCommand is not IDisposable.

    Since it has a .Connection property arguably it should have been. But the idea seems to have been that one connection would be associated with multiple SQLCommand objects and hence would need to be disposed separately when all DB access was complete.

Leave a comment on “Nada”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article