Steve Jones - SSC Editor (3/29/2013)

---

jfogel (3/29/2013)

---

I agree that if you are vigilant with security then xp_cmdshell is just fine and I've used it for years. However, over the last year or so I've started to turn away from it and not for security reasons. I've been trying to challenge myself to avoid it and find another way to accomplish a task that I would typically use it for. As an example, I setup an agent job recently that compresses some files and copies them to a DR Site and normally I'd use cmd shell to compress the files using PKZip or something but this time I used a powershell function. I didn't want to install any compression program on the production database server and I wanted to avoid a call to cmd shell and I was able to avoid both.

There is a limit to how much effort I'll go through to avoid it, though. I can always use the powershell compression function in other tasks but if I were to find myself having to create all sorts of things to replace the functionality of cmd shell then to me it means making a mess and reinventing the wheel.

I would say Powershell is better if you can call things from a job, but you can't necessarily do that from T-SQL. That's a bit of an issue. I wish we had a ExecPS('') function that would allow calling cmdlets. Course, XP_CMDSHELL does it just fine.