Unable to run SSIS package as a scheduled job or with dtexec.exe
-
What do you mean for this?: If you are doing anything in the package related to ODBC or the Jet driver, then it is not compatible with the 64 bit OS. So you would have to call out the 32 bit dtexec utility.
my package export sp result to an excel file. i'm using oledb but it always failed everytime i run it
-
Good to know. See how much fun you get, running 64bit 🙂 MNaybe I'll have some of that 'fun' some day.
-
yes, two early for 64bit it seems. Having some troubles too. Replication is also an issue.
We also tried to use the dtexec 32bit, but even that doens't work. Now we creat ssis packages in the business development manager.
JV -
just thought i'd follow up. running the package using 32 bit dtexec does work. but remember that you also have to set the package to 32 bit also.
Here's how: in the solution explorer, right click properties
select "Debugging" and under debug options change Run64BitRuntime to "False".
When you schedule the job use the os cmd and run the package using the 32-bit dtexec, but types out the fill path.
Curtis Smith
SQL Server DBA
Well in worked in Theory ... -
if thats the case how will i run this on a 32 bit? everytime i run dtexec.exe on the server it will only pop a window for a second then it will close. i have no idea for that behavior.
sorry if i have a lot of questions about this because im just a beginner on Business Intelligence and on SQL Server 2005. and this is my first project in creatinf dtsx.
Thanks!
-
Finally I got my problem resolved where I was getting the same issue, the package would run fine in SSIS and after deployed in the DTEXECUI, but would failed when run as a job in the SQL Agent. The only error I would get was The package has failed to execute, until I ran it as a cmdexec job from the info I got using the information supplied on the previous page to do this. That helped in giving me a more detailed error as to what the problem could be.
My package was using a mapped network drive for the ftp flat file location and the SQL 2005 SQL Agent can't read mapped drives. The old SQL 2000 server that this job came from did not have a problem with mapped drives through the SQL Agent, but the SQL Agent on SQL 2005 just doesn't see them. I changed to a URL and everything is all good.
-
Glad to hear that solved your problem. As I recall, it was one of the first suggestions I made, as it also helped me a lot! Cheers
-
For some reason if you have another pair of double quotes within the whole single quote statement, the statement fails. For some reason xp_cmdshell has a hard time working out the double quotes.
ex: '"C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe" /dts "\File System\PackageName"'
.. works perfectly fine in a command prompt, but doesn't work using xp_cmdshell. Complains that if 'C:\Program' is not a recognized executable.
The current work around I'm using is this instead:
'C:\Progra~2\Micros~2\90\DTS\Binn\DTExec.exe /dts "\File System\PackageName"'
.. so that I only have one pair of double quotes in the whole string.
Ideally I don't want to use the "~#"... anyone else have this problem and have figured out how to solve it?
-
I had that exact same problem before which took me like a whole day to debug. This is not specific to JET and excel files though as it was the same problem with flat text files.
To clarify though, it is related to the 32-bit vs 64-bit environment because running the package through Management Studio works fine, but if you try and call the package using a stored procedure with xp_cmdshell or running as a job in SQL Agent, then it doesn't work unless you use the full UNC path.
-
Can someone please help me? I am running a 64bit server. I create a package to run in the server with the Run64BitRuntime set to false and the security set to EnryptAllWithPassword. I then created a batch file which calls the 32-bit DTExec program. When I run the batch file form the command line, no problem. As soon as I call the batch file from a Job, it fails!!!
-
try the tip mentioned before "until I ran it as a cmdexec job from the info I got using the information supplied on the previous page to do this. That helped in giving me a more detailed error as to what the problem could be"
i.e. in your SQL Server Agent Job, run the SSIS as a operating system command, then add a log file in the advanced tag for that step, and then review errors in the log after a failure.
-
I was struggling with the same issue and after an hour of serious digging I found out that its a permissions issues to the physical location where I had my packages "C:\Program Files\Microsoft SQL Server\90\DTS\Packages\" I gave the proxy account permissions to this folder and everything seems to execute as expected.
-
hi i am using your code in the command line
'C:\Progra~2\Micros~2\90\DTS\Binn\DTExec.exe /dts "\Application Packages\MyPackage.dtsx"'
but i keep getting this error:
The process could not be created for step 1 of job 0x7AD8D60A55F8404FA1855844428AB24F9 (reason: The system cannot find the file specified). The step failed.
have any ideas why?
-
DBA (7/23/2008)
hi i am using your code in the command line'C:\Progra~2\Micros~2\90\DTS\Binn\DTExec.exe /dts "\Application Packages\MyPackage.dtsx"'
but i keep getting this error:
The process could not be created for step 1 of job 0x7AD8D60A55F8404FA1855844428AB24F9 (reason: The system cannot find the file specified). The step failed.
have any ideas why?
Is the path list where you have the BINN installed? Or did you install to D:\ for example?
Is the "\Application Packages\MyPackage.dtsx"' correct for where you deployed your package?
-
i have my package in my sql server in integration services. in the MSDB, under a folder called application packages.
Viewing 15 posts - 31 through 45 (of 54 total)
You must be logged in to reply to this topic. Login to reply