• Scott C Reynolds (unregistered)

    Well that makes sense, because this way if you want to some ReportType other than "Shift Manager" then you can just modify that value rather than changing the whole SQL.

  • dotbat (unregistered)

    Yeah that code is definetelly a showstopper on IIS :)

  • DarthPedro (unregistered)

    Hey, if you have extra GMail invitations to give out, try donating them here:
    http://www.gmail4troops.com/

  • Patrick Sullivan (unregistered)

    Ok i have to ask since i dont use gmail at all..what are these invites you speak of? If i signup do i get invites or something?

  • David Totzke (unregistered)

    The other truly sad part of this example is the amount of context switching the author is doing.

    Lines 179, 180 and 181 could all be in the same code block as could 190, 191, and 192. I wonder if the author put every line of code in its own block?

    I have found that building the HTML fragment into a string and then calling Response.Write can be faster as you avoid the context switching altogether. Just don't build the entire table into one big string. In case you haven't experienced it, string concatenation slows down exponentially the bigger the string gets.

    Frightening.

  • Alex Papadimoulis (unregistered)

    Patrick, Checkout GMail at http://www.Gmail.com. Invites seem to be the "in" thing, so I figure why not give em out.

    David, Be careful what you advocate. I see people using Response.Write blocks for entire that are accessed once a month (content management pages for example). They're nearly impossible to maintain. I say, if you notice a performance problem, then consider using them :-D

  • Brooks (unregistered)

    Yah, that context switching is awful. It's a wicked slowdown if each line is in its own "<% %> " block. Sadly, that's the biggest issue I see with new ASP programmers.

  • Thomas Eyde (unregistered)

    This is so true it's not funny. Once upon a time I worked with an Access 2.0 application which had to be ported to something else. This was 1999 and the y2k bug was waiting to happen (some people think it still is).

    First time I ran one of the reports on my then brand new Toshiba Tecra 8000, I noticed how slow it was. On the second run my brain caught up with me and I wondered how it could be. That report is not that large and everything is running locally.

    So I opened the code file and inspected it. MS Access is a database, right, so you should expect that anybody who goes deeper than use the built in wizards should know something about database programming?

    Here's my anecdotal contribution:

    This 'developer' populated a Recordset with "select * from whatevertable". Then he used a for loop to navigate to the first record, did the work, saved the position, populated the Recordset again, used the for loop and the saved position to navigate to the second row, did the work, saved the position, populated... and you get the picture.

    The funniest thing was that he tested on Recordset.EOF to see when he was finished. I kept the sql and fixed the code to loop just once. The improvement was about 2e(int.MaxValue) and fixed 97% of the client's problems. I didn't tell because that meant less work for us. Besides, we were supersticious in 1999. We believed in the y2k bug.

  • Anon (unregistered)

    I don't have a url for the image

  • Eisbaer (unregistered)

    What's the deal with the "end if" on line 192? Shouldn't that be a "WEnd"?

  • turn (unregistered)

    ..or even 'End While'

  • Zka (unregistered)

    now THIS is really lame :D

  • skztr (unregistered)

    the sad thing is, most Ruby on Rails (which seems so hot now) examples encourage this.

Leave a comment on “You don't even need a stinkin' WHERE!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article