• Steve Jones - SSC Editor (8/1/2013)


    patrickmcginnis59 10839 (8/1/2013)


    paul.knibbs (8/1/2013)


    That's all true, but I come from a programming background, and I know that you will pretty much never, ever anticipate every daft or incorrect input a user is capable of providing. 🙂

    In my case, instead of ceasing programming, I instead looked for ways to simulate daft input, and have generalised this further into putting filters on input that required conditions to be "non daft" in nature 🙂

    Not a perfect situation, I've been surprised before, made errors before, but in my opinion, during the course of scripting a task we can compress all of the analysis and synthesis of error handling into the exercise of scripting, whereas Hugo is stuck repeating all that analysis and synthesis DURING EACH MANUAL RUN OF HIS TASK.

    There are risks either way, but you have to choose some method. The thing I'd say with a script is that I have the advantage of logging what happened and being able to debug it when I've made a mistake.

    If I've clicked on a button, I am relying on my own (highly suspect and faulty) witness testimony to trace back the actions.

    This is one of the biggest pros of using a script. It is reproducible and provides a "logging" mechanism of what has been done (almost self documenting). If that logging is not adequate, you can modify it to output to a log (file or table) what has been done and provide timing measures.

    Though it is not foolproof, it can be easier to "debug" and discover what went wrong and where it went wrong.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events