• (cs)

    HEY! BeagleSoft stole MY PROGRAM named TODO!!

  • MyName (unregistered)

    Please, oh please, tell me this is a lie. Pretty please.

  • The Mr. T Experience (unregistered) in reply to ParkinT
    ParkinT:
    HEY! BeagleSoft stole MY PROGRAM named TODO!!
    TODO: Be Funny
  • anonymous (unregistered)

    i don't get it. what's a "where clause"?

  • Nagesh (unregistered)

    Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

    [image]
  • Ross (unregistered) in reply to MyName

    Why? Do you work at Beaglesoft?

    The sad thing is that this is not a one-off. Any supposedly production SQL that starts 'SELECT *' is bogus.

  • mrfr0g (unregistered)

    @Ross

    I believed that as well until I started work at my last job (the company has since gone under). Most of the site was developed by an external contractor and I was hired to come and clean up his mess. It was typical to see pages that started with;

    SELECT * FROM Table1 SELECT * FROM Table2 SELECT * FROM Table3

    Then later in the page a new query was generated to get the data that was actually needed;

    SELECT UserID from Table1

    Of course he didn't use the where clause, instead he used a for loop to find the user he wanted. And yes, the tables were named, Table1 - 26.

    Suscipere - The act of acting suspicious, while acting suspicious.

  • (cs)

    The Dentist. The arch-foe of any geek out there! Especially of those who create their own companys and give out shares!

  • MojoMonkeyfish (unregistered) in reply to Ross
    Any supposedly production SQL that starts 'SELECT *' is bogus.

    I wouldn't say that. Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for. That means, there shouldn't be any superfluous columns you need to filter out.

    The job I'm currently working is all CQRS/EventSource, so there's pretty much a 1:1 correspondence between use cases and tables.

    As a very database-centric developer for most of my career, it took some adjustment, but it's an exceptionally fast and scalable model.

    Anyhow, all our "production sql" is "SELECT *", and it hasn't been an issue for us at all.

  • Austin (unregistered)

    Wow, I may not be first but

    FRIST !!!

  • (cs) in reply to MyName
    MyName:
    Please, oh please, tell me this is a lie. Pretty please.
    Did you really not see this coming when you read the following?
    Alex:
    “While our prices might seem high,” a Beaglesoft rep once told Aaron, “keep in mind that you’re paying for quality. Our products are rigorously tested to work in today’s and tomorrow’s high-tech dental office.”
  • (cs)

    > The system had completely grinded to a halt.

    I finded that a strange sentence.

  • Sock Puppet #5 (unregistered)
    The Article:
    Dr. Strickland, and demanded that there was foul-play involved.

    Dr. Strickland, in the dentist office, with the online-all-the-time.

  • Sock Puppet #5 (unregistered) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    MyName:
    Please, oh please, tell me this is a lie. Pretty please.
    Did you really not see this coming when you read the following?
    Alex:
    “While our prices might seem high,” a Beaglesoft rep once told Aaron, “keep in mind that you’re paying for quality. Our products are rigorously tested to work in today’s and tomorrow’s high-tech dental office.”
    It was clear that it worked fine on Friday (today) and Saturday (tomorrow).
  • (cs) in reply to Cantabrigian
    Cantabrigian:
    > The system had completely grinded to a halt.

    I finded that a strange sentence.

    bind -> bound find -> found wind (long 'eye' sound) -> wound grind -> ground

    but

    blind -> blinded mind -> minded (your own business) wind (short 'i' sound) -> winded (usually only in passive voice)

    It's English that you should find strange.

  • Weeks before D-Day (unregistered)

    I kept on wishing that he would use the notion of timing by D-Day right, and call it "D minus 7", instead of "a week before D-Day". Has no one seen a launch and heard "T minus 30" and thought "hey, that's a cool way to tell time." Or seen "Private Ryan" and "D plus 3"?

    CAPTCHA: jugis - latin for hot chicks?

  • (cs)
    Our products are rigorously tested to work in today’s and tomorrow’s high-tech dental office.
    Really? What about on Monday, July 19th? Cuz that's when we really need it to work.
  • Mike (unregistered)

    One time I wrote: SELECT * from TEETH but forgot the: WHERE CAVITIES > 0

    ...so now I have to drink my food.

  • Shutterbug (unregistered)

    Anyone else noticed that Nagesh appears to have got a new camera for Christmas?

  • Weeks before D-Day (unregistered) in reply to MojoMonkeyfish

    I hope this is sarcasm....

    In case it isn't, besides the horror of making views to correspond to the columns you need for every current query, your maintenance programmers will find you in your sleep and kill you if you ever need to add a column to a table.

  • (cs) in reply to Sock Puppet #5
    Sock Puppet #5:
    The Article:
    Dr. Strickland, and demanded that there was foul-play involved.

    Dr. Strickland, in the dentist office, with the online-all-the-time.

    No, it was Dr. Atkinson, in the server closet, with the "T1 Spike".

  • Geoff (unregistered) in reply to MojoMonkeyfish

    I don't know. Would it be that hard to specify the attribute names you want though? I mean seems to me doing so actually reduces the coupling, which is generally a good thing.

    If you are using SELECT *, and anyone changes that view/table your app is going to break. Well unless you are testing the attribute name in the record set your api returns, in which case you have accomplished nothing other than saving a few bytes in the select statement.

    If you specified the attributes, then the order of columns in the table would not matter, and additional columns could be added. I guess you could always just make another view though as you say that preserves the original table appearance.

    Still I feel like its just good form to list out the attributes, unless there is a specific reason not to do so. The real WTF naturally is not using the database engine to the filtering. Lake of join criteria or a WHERE clause is pretty unforgivable; that an anything that changes data should probably use a prepared statement; as should anything that is of sensitive nature if it is read only.

  • Anon (unregistered)

    Im qualified to be a leading developer all this time and I didnt know it

  • Nagesh-saki (unregistered)

    This was a nasty problem we found in ADO recordsets. To append a record, ADO did a select * behind the scenes.

  • Medinoc (unregistered)

    I actually wonder how it did all end up for the doctors (or whoever was anonymized into four doctors).

  • Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)! (unregistered) in reply to @Deprecated
    @Deprecated:
    Sock Puppet #5:
    Dr. Strickland, in the dentist office, with the online-all-the-time.
    No, it was Dr. Atkinson, in the server closet, with the "T1 Spike".
    No, it was Nurse Hanlon, on Dr. Strickland's desk, with the AIDS.
  • Harrow (unregistered)

    My heart bleeds for the "Associates".

    -Harrow.

  • Tom (unregistered) in reply to Ross
    Ross:
    Any supposedly production SQL that starts 'SELECT *' is bogus.
    I'm going to join in disagreeing with this, because I have this marvelously flexible language called Perl. You can "SELECT *" into a hash, which will automagically create a hash entry for each column. Then your code can say things like: 
    if $att{price} > 10 ...

    If the new attributes are added to the table, you don't have to modify any code. It is even update-safe.

    $att{status} = 'x';
$att{date} = $Today;

    Then you can write the whole row back and the hash is transformed back into a row again. Otherwise you'd need to do separate SQL updates for each attribute?? What a pain!

  • (cs) in reply to Tom
    Tom:
    Ross:
    Any supposedly production SQL that starts 'SELECT *' is bogus.
    I'm going to join in disagreeing with this, because I have this marvelously flexible language called Perl. You can "SELECT *" into a hash, which will automagically create a hash entry for each column. Then your code can say things like: 
    if $att{price} > 10 ...

    If the new attributes are added to the table, you don't have to modify any code. It is even update-safe.

    $att{status} = 'x';
$att{date} = $Today;

    Then you can write the whole row back and the hash is transformed back into a row again. Otherwise you'd need to do separate SQL updates for each attribute?? What a pain!

    HA! You had me there for a second...
  • Richard (unregistered) in reply to MojoMonkeyfish
    MojoMonkeyfish:
    Anyhow, all our "production sql" is "SELECT *", and it hasn't been an issue for us at all.

    An advantage of specifying the column names is that you may detect bugs quicker and you may make the system more robust, especially if you index the returned result set by column number not name.

    An advantage of selecting * in some environments is less code change if you add fields, but the environments I work on use an object relational layer so I don't actually end up typing this stuff in production code, and things are more nailed in anyway.

    SELECT * interactively, when exploring a database, is great though.

  • Richard (unregistered) in reply to Mike
    Mike:
    One time I wrote: SELECT * from TEETH but forgot the: WHERE CAVITIES > 0

    ...so now I have to drink my food.

    At least it wasn't

    DELETE FROM TEETH;

  • Bananas (unregistered) in reply to Richard
    Richard:
    Mike:
    One time I wrote: SELECT * from TEETH but forgot the: WHERE CAVITIES > 0

    ...so now I have to drink my food.

    At least it wasn't

    DELETE FROM TEETH;

    At least it wasn't

    TRUNCATE TABLE TEETH;

  • (cs)

    I was going to do a thing about "steenking 'Where' clause", but realized it would be an insult to Mexican bandits (who are surely way smarter than the Beaglesoft developers).

  • Cbuttius (unregistered)

    A WHERE clause is not enough, the table would also need to be indexed.

    Also, of course, ensure your query is protected from SQL injection.

    Now I only wish I'd known there was a job available at such a great IT company in July 2004.

  • Why'd he turn it down? (unregistered)

    Working for a company that can sell a plug and play USB camera for $7,000, and they'll think I'm a technical deity for being not incompetent?

    Seems like it could be fun.

  • Jay (unregistered) in reply to MojoMonkeyfish
    MojoMonkeyfish:
    Any supposedly production SQL that starts 'SELECT *' is bogus.

    I wouldn't say that. Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for. That means, there shouldn't be any superfluous columns you need to filter out.

    The job I'm currently working is all CQRS/EventSource, so there's pretty much a 1:1 correspondence between use cases and tables.

    As a very database-centric developer for most of my career, it took some adjustment, but it's an exceptionally fast and scalable model.

    Anyhow, all our "production sql" is "SELECT *", and it hasn't been an issue for us at all.

    I'm hoping this is a troll.

    If not, well: "Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for." That's absolutely insane. That assumes that you create a new table for every query you write. Can you really not imagine having, say, a "customer" table, or an "employee" table, that is used in many different places in your systems?

  • Jay (unregistered) in reply to Cbuttius
    Cbuttius:
    A WHERE clause is not enough, the table would also need to be indexed.

    Also, of course, ensure your query is protected from SQL injection.

    Now I only wish I'd known there was a job available at such a great IT company in July 2004.

    Well it is certainly good if a table has appropriate indexes, even if it has no indexes at all you'd be better off to have a WHERE clause. At least then the selection would be done on the server and only qualifying rows transmitted over the network.

  • (cs) in reply to Cbuttius
    Cbuttius:
    A WHERE clause is not enough, the table would also need to be indexed.

    Also, of course, ensure your query is protected from SQL injection.

    So at least there practice is immune to such attacks!
    Cbuttius:
    Now I only wish I'd known there was a job available at such a great IT company in July 2004.
    It appears this company is still around: (B)Eaglesoft

    And it appears Akismet still sucks donkey nuts!

  • (cs)

    I'm not usually one to call BS on a story posted here, but I have to wonder about this one. How is it even possible to learn SELECT ... FROM but be completely ignorant of WHERE?

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    I'm not usually one to call BS on a story posted here, but I have to wonder about this one. How is it even possible to learn SELECT ... FROM but be completely ignorant of WHERE?
    Probably more lazy than anything else. The developers probably just didn't want to write [GASP] a new stored procedure for different searches which return different information.

    Also, by not having a where clause, they're effectively sql injection proof!

  • Jay (unregistered)

    "WHERE clauses and other optimization techniques". A memorable phrase if I ever heard one. I've got to use that.

  • Tonsil (unregistered)

    Trolls notwithstanding, one thing about the SELECT * approach to keep in mind: If you are joining multiple tables with one or more identical column names, the results could be unpredictable, depending on how your software handles it. For example, if the result gets dumped into a hash, perhaps the last distinctly named column is stored. If the tables' structures change, this could affect the code.

  • Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)! (unregistered) in reply to MojoMonkeyfish
    MojoMonkeyfish:
    No one is that stupid.
    I disagree. I'm that stupid.
  • vic (unregistered)

    They forgot to mention that tomorrow's high-tech dental office has networks with infinite bandwidth and warp-speed transfer rates, and computers with infinite memory whose processors are so fast that the results are returned before the instructions are even executed.\

    and as much as I hate to add a cheesy captcha comment, captcha "iusto" - just add a tail to the first letter to make it truly cheesy (in Finland)

  • (cs) in reply to Nagesh
    Nagesh:
    Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

    [image]

    That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    I'm not usually one to call BS on a story posted here, but I have to wonder about this one. How is it even possible to learn SELECT ... FROM but be completely ignorant of WHERE?

    You will find difrent kinds of people in development teams. Lack of training make that happen. It is important to train resource once you grab them from colege. I had to undergo six weeks of training before they let me work on live project. Another six month, before I was billing member of team.

  • Jerry (unregistered) in reply to Nagesh
    Nagesh:
    I had to undergo six weeks of training before they let me work on live project. Another six month, before I was billing member of team.
    I call B.S. We all know the only training people from your fine offshore country receive is how to make your "R"s sound like a rattlesnake.
  • Nagesh (unregistered)

    Visiting dentist in Hyderabad is being very dangrus. Much hookah smoke in closed area cause medical problam for woman and childs.

    [image]
  • facilisis (unregistered) in reply to Nagesh
    Nagesh:
    Nagesh:
    Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

    [image]

    That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.

    Is this what passes for entertainment in India? You guys need TV!

  • (cs) in reply to Nagesh
    Nagesh:
    That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.
    Who used to own him?

Leave a comment on “Classic WTF: Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article