• This is a good subject. The military realized the fallacy of "If it ain't broke, don't fix it." a long, long time ago. Daily, weekly, monthly, quarterly, yearly, and "as required" maintenance procedures for virtually every piece of equipment is available, scheduled, and required to be completed. It's why we win wars... it helps keep stuff from breaking when you can least afford it to.

    It's too bad that most people don't consider the same with most software. Good DBA's do by checking their overnight "health check" runs and whether or not their permanent "low hanging fruit" profiler run for RPC Complete and SQL Batch Complete picked up anything out of the ordinary. Good GUI designers will also put parametrics into their system to measure and log such things as the time it took to render and present a page, etc.

    Sadly, not enough people take the time to do all of that. All they really care about is "time to market" and "it's good enough for this release". Rarely do they care about future performance (including up time) and the like because they don't even care about it in the present. "Wrap it and ship it" has become the mantra for many. "Set it and forget it" is the normal follow up to that.

    [font="Arial Black"]"If you want it real bad, you'll likely get it that way."[/font] -- Jeff Moden, circa 2003

    😉

    --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)