March 27, 2012 at 1:38 pm
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
March 27, 2012 at 1:46 pm
Execute Process.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
March 27, 2012 at 2:17 pm
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
March 27, 2012 at 2:38 pm
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
March 27, 2012 at 2:46 pm
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
March 27, 2012 at 2:53 pm
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
March 28, 2012 at 9:08 am
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
March 28, 2012 at 9:26 am
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
March 28, 2012 at 10:05 am
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
March 28, 2012 at 11:13 am
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
March 28, 2012 at 11:30 am
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
March 28, 2012 at 11:38 am
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
July 6, 2015 at 12:11 pm
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?
July 6, 2015 at 12:30 pm
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
July 6, 2015 at 1:03 pm
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