• SoHelpMeCodd (8/4/2015)


    Just for some color.

    Let's imagine a harangued writer in SQL Server's documentation ("user education") team, one who cannot write about the new features until *after* the feature is finalized (barring a new bug causing feature changes). Back in 2000 era, some developer screams about the obvious security flaw within that era's xp_cmdshell implementation, so a dire warning about xp_cmdshell's security flaws is written (and makes it into BOL). So be it.

    Years pass (5 years, to be exact), with new features piling up (all of which need lucid and voluminous documentation/user education). The original writer has moved on (5-years of absolute boredom can cause a writer to go bonkers well before the new release's punctuated moments of shear terror). So a new documentation writer adds xp_cmdshell's new proxy feature. Unfortunately, that new writer is oblivious about the 2000-era author's reason for xp_cmdshell's dire warning ("I don't know why that thing is there. Best to leave it alone."). Not many I know will question what is already in black and white. Or maybe that new writer has not read the 5-year old dire warning about xp_cmdshell in BOL (authoring tools help when one must wade thru more than 50,000 pages of accumulated documentation, by putting blinkers over one's eyes). Or maybe the new writer has other more important matters to address, such as a 5-year backlog of new features that seriously need some user education.

    So goes the bureaucracy for large projects, such as one where over 500 people wrote code and less than 50 wrote documentation. Can this juggernaut be changed, by us mere users who might connect and request a reduction in the direness of a 15 year old warning (where both writers have now retired, perhaps with the UE team now outsource)? I sort of doubt it - and you can call me jaded :).

    Thanks for the feedback on this...

    Dunno for sure but the answer is always "NO" unless you try but I know what you mean. There are people out there that still think that SELECT INTO will totally lock up TempDB (like it used to pre 6.5 SP1) and thusly bring the server to its knees and they still resist even when I show them the SP documentation that fixed it.

    Anyway and to be sure, it's not my goal to convert people to using xp_CmdShell. It's my goal to educate them and let them make their own choice. For some, it might be a bit of a re-education because of the "original documentation" that you speak of.

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