• I'm in the "usually avoid both" camp, although there's always the rare exception.  In many cases that I've seen, people are simply using PowerShell to do things that should actually be done in SQL Server.  In fact and as some have already pointed out, many have taken to writing PowerShell to run SQLCmd instead of building a stored procedure.

    Sure, there's some huge utility in both PowerShell and SQLCMD but they shouldn't be used as a replacement for stored procedures nor should they be used to build things like centralized backups, as seems to be all the rage.  Just imagine what will happen to the log files on all of the remote systems if that centralized back system goes offline or fails.  If that happens, I hope you have an excellent script to properly shrink and resize all of your transaction log files on those other systems. 😉

    Just as people say about SQL, so it is true with PowerShell.  "Just because you can do something in PowerShell, doesn't mean you should."

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