Who knows what your reason for doing so may be. Maybe it's to launch some PowerShell functionality from T-SQL. Maybe it's to do BCP OUT or some file handling. Whatever it is, if you could do it from T-SQL in a super secure manner where the user of a stored proc with xp_CmdShell in it couldn't run xp_CmdShell directly him/herself and had nothing more than standard PUBLIC privs on the given database, would you use xp_CmdShell?
Just to throw my use for it into the ring to get things started, I use xp_CmdShell in the secure manner described for ETL (both in and out) along with some necessary file handing in the very secure method I suggested instead of using SSIS packages. I've also used xp_Cmdshell with VBA to create and export to some rather colorful spreadsheets. I understand that Powershell is even better for that task and am considering making calls to Powershell from T-SQL to do just that.
And, no... this isn't an SSIS bashing party. I just want to know, if you could use xp_CmdShell securely, what might you use it for and would you actually use it? xp_CmdShell bashing and praising is absolutely welcome. :-) Just be careful not to bash me on the subject. I'm just trying to get a friendly conversation started on what normally terns out to be a highly controversial subject because I'd like to know what others think on the subject. ;-)
is pronounced ree-bar and is a Modenism for R
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs