Unable to run Batch file though T-SQL (Xp_cmdshell)

  • Hi All,

    I'm unable to call the .Bat file through T-sql (using EXEC master..xp_cmdshell 'Call G:\abc\xyn\execute.Bat'. It just throws the error as below: (Bat file contains sftp2 command)

    'sftp2' is not recognized as an internal or external command,

    operable program or batch file.

    Where the same executes fine through CMD window. I guess somw issue with the accounts that run the SQL. Please help.

  • it could be a PATH issue..

    try running 'sftp2' using xp_cmdshell.

    make sure location of sftp2 is in PATH when the batch file is executing..

    Vishal Gajjar
    http://SqlAndMe.com

  • Please don't forget to follow the discussion.

    I cringe every time I see a recommendation for xp_cmdshell.

    http://qa.sqlservercentral.com/Forums/FindPost1186236.aspx

  • just include SET PATH = %PATH%;C:\thisfolder\thatfolder as a line in the script, to where sftp2 resides.

    It only sets it for the session, not as a global permanent setting, so no permanent changes made.

    ---

    Note to developers:
    CAST(SUBSTRING(CAST(FLOOR(NULLIF(ISNULL(COALESCE(1,NULL),NULL),NULL)) AS CHAR(1)),1,1) AS INT) == 1
    So why complicate your code AND MAKE MY JOB HARDER??!:crazy:

    Want to get the best help? Click here https://www.sqlservercentral.com/articles/forum-etiquette-how-to-post-datacode-on-a-forum-to-get-the-best-help (Jeff Moden)
    My blog: http://uksqldba.blogspot.com
    Visit http://www.DerekColley.co.uk to find out more about me.

  • I'd say its a permissions issue, since the bat file works from a command window.

    this is a common security misconception/"gotcha". The problem is that when you access any resource OUTSIDE of SQL server, like network shares, local hard drives and folders,xp_cmdshell, sp_OA type functions etc.

    it doesn't matter what YOUR credentials are. Whether you are Domain Admin,Local Admin , logged in as sa, administrative login on a laptop, etc, because SQL will not carry those credentials to the "outside of SQL" security context.

    SQL WILL pass your credentials to a linked server, but anything else is using an account you did not intuitively expect it to use.

    SQL Server uses either the account set up as the proxy account, or if that is left blank(the default) it uses account it starts with to try and access the resource:

    or if the above was blank, the account in services:

    That account is often an account which has never logged into the domain, and was never assigned permissions to get to the local disk or network share.

    As a result, you usually need to create a domain account in Active Directory, specifically grant it share access if it doesn't inherit it from Domain\Users or Domain\AuthenticatedUsers and change the account SQL Server starts with to that account.

    Once that is done, and you stop and start the SQL service to make it use that account instead of old running values, your linked server/xp_cmdshell would work.

    you can prove this is the issue by simply putting in your credentials, with your domain account and password, and confirm the external object you were trying to access/use works when SQL is run your credentials, so you'd know you need either a local account (for local disk access) or a domain account(for network shares) to access the resource.

    [/quote]

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Thanks for your help. It got resolved

    I gave complete path of sftp2 in bat file and this made the things working

  • Dev @ +91 973 913 6683 (10/19/2011)


    Please don't forget to follow the discussion.

    I cringe every time I see a recommendation for xp_cmdshell.

    http://qa.sqlservercentral.com/Forums/FindPost1186236.aspx

    Yes... please follow ALL of the discussion because if you can't use xp_CmdShell in a proc without giving someone more than just PUBLIC privs, then your system is still vulnerable to attach whether you're using xp_CmdShell or not. 😉

    --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)
    Intro to Tally Tables and Functions

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply