• A short, sweet, and brilliant article! Bravo Stephen and spot on on all points especially on working with your "customers".

    There's only one problem with the scenario you're given... what if the "customers" had said the data had to be "up to date" as in "to the second" (or so)? That probably brings us to the real problem of not having enough time because of poorly estimated schedules or the corner office wants it real bad and, obviously, got it that way or no one really gave a damn when it came to design and coding. It's one of the reasons why I say to always plan and program as if there were at least million rows in each and every table.

    I don't know about others but I gave this article 5 stars for the message it carries about working with the customer. By the same token, I could have given this article MINUS 5 stars because (not having ANYTHING to do with the author) [font="Arial Black"]the boss actually isn't a hero [/font]because he is the one that should have managed things in such a fashion to PREVENT such problems from happening to begin with.

    Tell your boss I said "Welcome to the Lucky Rollers Club" and to start taking care of business because the answer could have been a whole lot different. 😉

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)