drew.allen - Monday, October 23, 2017 3:15 PM

kding - Monday, October 23, 2017 10:37 AM

drew.allen - Monday, October 23, 2017 9:32 AM

sgmunson - Monday, October 23, 2017 8:23 AM

kding - Saturday, October 21, 2017 5:14 PM

Eirikur Eiriksson - Saturday, October 21, 2017 6:28 AM

Quick thought, add error handling in the exe code with specific error numbers, then you at least will have a chance of knowing what is going wrong.
😎

Thank you for your reply. I will try to add error handling to the c# code. I think it may be some access issue so the exe only runs half way. I will post my find out.

Kevin

When you run the package, you probably do so within Visual Studio, and you get your id as the execution context.   When you run the package as a job step in a SQL Agent job, the id that is used for the SQL Server Agent service is used instead, and IT must have the necessary file permissions to access the executable file as well as the data file source and destination folder locations.

To follow up on this, the default account used for SQL Agent jobs is a SQL-only login, so it will not have rights to your file system.

John

Thnk you John. I thought about this too. I was login as SQL server agent account when I run the package to avoid this access issue. The package runs fine but not the job.

Kevin

You should also always use UNC paths instead of drive letters.  The E:\ drive when you run it on your machine is not going to be the same as the E:\drive when it runs on the server.

Drew

PS: Sorry about signing the previous post John.