Heh... read my post. I didn't say you called me any names. Normally it takes some name calling to get a PM like that from someone and I'm just making sure that you're aware that I've called you no names. It's also presumptuous to think that getting such a PM in the middle of a heated debated would be enjoyed by anyone (especially from a friend), even those of us that were in the Navy. Using words like "xp_CmdShell is a s-----y tool" also implies that I'm a "s-----y" Developer and I take offense to it much like you took offense to Sergiy's use of the word "Cowboy" and other words. It wasn't directed at you and you didn't direct "s-----y" at me, but we are both offended, none the less.

You have insinuated that my point of view (and, therefor, me) is ridiculous and unreal (heh... you managed to do both in the post above). I could say the same of you because, until they make an option to permanently disable xp_CmdShell from outside of SQL Server, no argument for disabling it will hold water against an "SA" level attack and, yet, you press on with that notion. Whether we agree or not (and I know we never will and that's OK) on the use of xp_CmdShell, both of our goals should be to warn people about what can be done during an "SA" attack even if xp_CmdShell is disabled.

As for the response proposing the use of xp_DirTree shifting to xp_CmdShell (and you and I obviously think differently on the subject), I actually believe that using xp_CmdShell is safer than using xp_Dirtree because xp_DirTree IS undocumented and could go away or change at any time just as xp_GetFileDetails did. I also believe that having SSIS Developers writing file handling scripts in VB or whatever to be executed from SSIS, is no safer than having an SQL Developer doing the same with a different tool but at least I'll have the opportunity to review the T-SQL solution as a DBA.

As a side bar, it would be nice if MS would realize that both their flagship ETL product and database engine tools are sorely lacking in many areas thus requiring the use of such ancillary scripts and other excursions to the operating system including the use of unsupported but useful extended stored procedures. One should not have to know VB, C#, DOS, or PowerShell (or any of a dozen other scripting languages such as PERL) nor write custom programming (SQLCLR) to get things done between files and the database in an RDBMS system that has been around for more that 2 decades in one form or another.

Shifting gears back to what's really important, neither of us have been saints in our discussions on this subject. Let's renew our friendship and both of us change our tone on the subject even as we continue to agree to disagree so that we can explain to people that even if you decide to not use xp_CmdShell, you're still not safe just by disabling it. Other steps must be taken. Both the friendship and the message are worth saving.