How to run a file on a server thru SSIS

  • Hi,

    I have a bat file on another server to be run through a SSIS package on different server.

    The bat file is stored in C:\ePLUM\bin\ImportAll.bat

    I have an already created SSIS package, the last step will be this above one.

    I can give all the privielge/permission in the bin folder to everyone to execute this step.

    Which step should i add in the SSIS package to do this step.

    Regards,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • Execute Process.

    If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

  • Phil Parkin (3/27/2012)


    Execute Process.

    Thanks.

    Actually, When I double click the bat file, the results are :- txt file in another folder gets processed....

    But when I doing this execute Process task ( running as a package), the txt file doesn't get proceesed..

    I am selecting just file name in process step -->executeable

    Do i have to put more info in the execute process task.

    Regards,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • In your Exec Process task you may have to pass the location of the batch file as a parameter to cmd.exe. Check out the /C switch, from a cmd prompt:

    cmd.exe /?

    Example:

    cmd.exe /C "C:\ePLUM\bin\ImportAll.bat"

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • opc.three (3/27/2012)


    In your Exec Process task you may have to pass the location of the batch file as a parameter to cmd.exe. Check out the /C switch, from a cmd prompt:

    cmd.exe /?

    Example:

    cmd.exe /C "C:\ePLUM\bin\ImportAll.bat"

    cmd.exe /C "C:\ePLUM\bin\ImportAll.bat"

    When i run this from run cmd on the server, it runs successfully by processing hte file.

    So where should i put this step in execute process task??

    Sorry, I am novice with SSIS.

    Regrds,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • In the Process Tab:

    1. Instead of setting Executable to C:\ePLUM\bin\ImportAll.bat, set it to fully qualified path to cmd.exe (e.g. C:\WINDOWS\system32\cmd.exe on my workstation).

    2. Set Arguments to /C "C:\ePLUM\bin\ImportAll.bat"

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • opc.three (3/27/2012)


    In the Process Tab:

    1. Instead of setting Executable to C:\ePLUM\bin\ImportAll.bat, set it to fully qualified path to cmd.exe (e.g. C:\WINDOWS\system32\cmd.exe on my workstation).

    2. Set Arguments to /C "C:\ePLUM\bin\ImportAll.bat"

    Hi,

    i did as you advised..The execute process task is giving errors:-

    [Execute Process Task] Error: In Executing "\\Server-name\C$\Windows\system32\cmd.exe" "/C "C:\ePLUM\bin\ImportAll.bat" " at "", The process exit code was "1" while the expected was "0".

    P.S. The package is running at server X and the bat file has to be run at server Y.

    Regards,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • Oh no, it does not work that way. The executable will always run in the context of the operating from which you call it, not on which you call it. In other words, even though you are calling the copy of cmd.exe located on a remote machine, it is still executing on the machine running the SSIS.

    There are utilities that will allow you to do what you want. We refer to it as "remote execution", i.e. sending a signal to a remote computer to execute something locally. You can look into PowerShell Remoting to do this for you, or for a CmdShell-based approach you can look into PsExec.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • opc.three (3/28/2012)


    Oh no, it does not work that way. The executable will always run in the context of the operating from which you call it, not on which you call it. In other words, even though you are calling the copy of cmd.exe located on a remote machine, it is still executing on the machine running the SSIS.

    There are utilities that will allow you to do what you want. We refer to it as "remote execution", i.e. sending a signal to a remote computer to execute something locally. You can look into PowerShell Remoting to do this for you, or for a CmdShell-based approach you can look into PsExec.

    Ok I got it, So iam now doing it the simple way.

    I copied the SSIS package from Server X to server Y.

    Change the source connection oledb.

    In the execute process task, I did exactly what you said

    -->

    In the Process Tab:

    1. Instead of setting Executable to C:\ePLUM\bin\ImportAll.bat, set it to fully qualified path to cmd.exe (e.g. C:\WINDOWS\system32\cmd.exe on my workstation).

    2. Set Arguments to /C "C:\ePLUM\bin\ImportAll.bat"

    Saved the package .

    Run the package from Visual studio..everythign ran fine and file was processed.

    Now when I made a job (from SSMS, on same Y server) using that package and ran the job.

    It ran successfully but the file didn't process.

    What AM i missing ?

    Regards,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • HI,

    When I running from SSMS, query analzer

    :-

    EXEC master.dbo.xp_cmdshell 'C:\ePLUM\bin\ImportAll.bat';

    GO

    Then I am getting 3 rows affected

    'Proxy.exe' is not recognized as an internal or external command,

    operable program or batch file.

    NULL

    What does it mean?

    Regards,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • SKYBVI (3/28/2012)


    opc.three (3/28/2012)


    Oh no, it does not work that way. The executable will always run in the context of the operating from which you call it, not on which you call it. In other words, even though you are calling the copy of cmd.exe located on a remote machine, it is still executing on the machine running the SSIS.

    There are utilities that will allow you to do what you want. We refer to it as "remote execution", i.e. sending a signal to a remote computer to execute something locally. You can look into PowerShell Remoting to do this for you, or for a CmdShell-based approach you can look into PsExec.

    Ok I got it, So iam now doing it the simple way.

    I copied the SSIS package from Server X to server Y.

    Change the source connection oledb.

    In the execute process task, I did exactly what you said

    -->

    In the Process Tab:

    1. Instead of setting Executable to C:\ePLUM\bin\ImportAll.bat, set it to fully qualified path to cmd.exe (e.g. C:\WINDOWS\system32\cmd.exe on my workstation).

    2. Set Arguments to /C "C:\ePLUM\bin\ImportAll.bat"

    Saved the package .

    Run the package from Visual studio..everythign ran fine and file was processed.

    Excellent! A proof of concept.

    Now when I made a job (from SSMS, on same Y server) using that package and ran the job.

    It ran successfully but the file didn't process.

    Any output from the package? I find it helps to pipe the output to a file from the SQL Agent job step when debugging (see Step Properties > Advanced Page > Output File).

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • opc.three (3/28/2012)


    SKYBVI (3/28/2012)


    opc.three (3/28/2012)


    Oh no, it does not work that way. The executable will always run in the context of the operating from which you call it, not on which you call it. In other words, even though you are calling the copy of cmd.exe located on a remote machine, it is still executing on the machine running the SSIS.

    There are utilities that will allow you to do what you want. We refer to it as "remote execution", i.e. sending a signal to a remote computer to execute something locally. You can look into PowerShell Remoting to do this for you, or for a CmdShell-based approach you can look into PsExec.

    Ok I got it, So iam now doing it the simple way.

    I copied the SSIS package from Server X to server Y.

    Change the source connection oledb.

    In the execute process task, I did exactly what you said

    -->

    In the Process Tab:

    1. Instead of setting Executable to C:\ePLUM\bin\ImportAll.bat, set it to fully qualified path to cmd.exe (e.g. C:\WINDOWS\system32\cmd.exe on my workstation).

    2. Set Arguments to /C "C:\ePLUM\bin\ImportAll.bat"

    Saved the package .

    Run the package from Visual studio..everythign ran fine and file was processed.

    Excellent! A proof of concept.

    Now when I made a job (from SSMS, on same Y server) using that package and ran the job.

    It ran successfully but the file didn't process.

    Any output from the package? I find it helps to pipe the output to a file from the SQL Agent job step when debugging (see Step Properties > Advanced Page > Output File).

    Actaully as stated in my last post. I added another tsql step

    (EXEC master.dbo.xp_cmdshell 'C:\ePLUM\bin\ImportAll.bat';

    GO

    ) in sql agent job after SSIS,

    So iam getting in the output file :--

    Job 'Export_File' : Step 2, '2' : Began Executing 2012-03-28 13:10:43

    output

    --------------------------------------------------------------------------------------------------

    'Proxy.exe' is not recognized as an internal or external command,

    operable program or batch file.

    (null)

    (3 rows(s) affected)

    Regards,

    Skybvi

    Regards
    Sushant Kumar
    MCTS,MCP

  • I am running into the same issue via SSIS. I am trying to run the following:

    Execuable: cmd.exe

    Argument: /c "\\he_interface_test\c$\Program Files\McKesson\Supply Chain Management\BIN\batchfms.exe" login password

    The executable will run and hang, but no results. Nothing is logged, no outputs.

    I've looked all over and I can't seem to find the magic syntax to get this to complete successfully.

    Any ideas?

  • Make sure the called app isn't asking for user input, e.g. a login name or license required.

    If you run the app from a cmd shell directly under the same security context as your SSIS Package you can confirm it works outside SSIS first. Many times trying it interactively outside SSIS will uncover an issue.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • The .exe file accepts the username and password as part of the connection string when running it locally.

    For example:

    "C:\Program Files\McKesson\Supply Chain Management\BIN\BatchFMS.exe" username password

    I've also called it from a 3rd part task automation tool that successfully runs it as well.

    Is there some limitation to what SSIS will pass across for remote cmd?

Viewing 15 posts - 1 through 15 (of 17 total)

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