• Lynn Pettis (7/22/2014)


    Jeff Moden (7/22/2014)


    Also not being snarky, but I've found that the reason a lot of people turn to PowerShell is because they don't actually know what they're doing in SQL Server. For example, I've seen many a script for having PoSH do all backups for the entire enterprise from a central location. While that sounds fine, that makes the enterprise reliant on a single point of failure. It would be far better to use PoSH to distribute and activate standalone backup routines to the individual systems so that there is no single point of failure for this most important activity.

    SQL Server is pretty good at what it does and can do especially when you get a little T-SQL involved. To coin a phrase, "Just because you can do something in PowerShell, doesn't mean you should". See the sister-phrase to that in my signature line below.

    True enough. But you can say the same thing about T-SQL, just because you can doesn't mean you should. There may be some things that can be done easier in PowerShell than in T-SQL.

    We are finally getting to the point of automating much of our ASI (upgrades) processing out here in Afghanistan. What we are doing now during the draw down is developing processes they would have loved to have had in place as they geared up and were sustaining 20+ sites across Afghanistan (and beyond, have a site in England but Afghanistan staff no longer supports it). Things we are developing now are going to be used to make supporting other sites easier and standardized.

    One thing I have learned in my reading is that PowerShell 3.0 introduced Workflows and this are restart able over system restarts. A benefit here is if you are doing a system upgrade that requires a reboot, the PowerShell Workflow can pick up at the point of the restart. Pretty cool.

    Also, what may be painful in T-SQL may be easier to accomplish in PowerShell just by the nature of the process being automated.

    It really comes down to using the right tool for the job.

    Sounds like a really cool application for PowerShell.

    On the other thing about...

    True enough. But you can say the same thing about T-SQL, just because you can doesn't mean you should. There may be some things that can be done easier in PowerShell than in T-SQL.

    ...{snip}...

    It really comes down to using the right tool for the job.

    ... the point that I was trying to make is that a lot of people don't actually know what the "right" tool is nor do they know what the tool called "T-SQL" is actually capable of nor how easily it can solve a wealth of problems. As a result, they end up using the "wrong" tool(s), frequently resulting in the "Tower of Babel" syndrome, because that's all they know. Notice that I put "wrong" in quotes because if you don't know a different tool exists, then the tool you know and have fallen back on will seem like the "right" one.

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