ResultCode 2147942405

I am setting up some jobs in the Task Scheduler on one of my application servers (Windows Server 2008 R2 Standard.)  As I searched for information about this error code I came across a couple of instances where the suspected translation of the error code amounted to "access denied."  In my particular case, this is indeed the problem.  The service account I have specified does not have access to it's working directory structure.  Here are the links I am referring to;

http://www.pcreview.co.uk/forums/schedule-event-returns-2147942405-a-t2397429.html

http://www.mydefrag.com/forum/index.php?topic=3920.0;wap2

http://www.myitforum.com/forums/m216308-print.aspx

Although I haven't tried it, the third link suggests running the job from the command line which would appear to give a more detailed explanation as to the failure where it might actually cite "access denied." 

I am waiting for my request to grant access to the service account before I make another attempt to execute the job via the scheduler.

Bulk inserts when the files to be imported are not on the database server.

Here is the scenario.  I developed a C# console application which downloads files from the web and imports them into an SQL Server 2008 R2 database.  The application executed nightly on an application server and it had sufficient access to the directory structure where it downloaded files to from the web.  Within the application, the connection string to the server and database utilized a service account with integrated security.  In SQL Server, the service account was granted the bulk insert admin role as well as dbo. Given this setup, the expectations were that the executing application would be able to download the files to the working folder of the directory structure, then connect to the database server, initiate and successfully execute a bulk insert request.  What happended instead?

Cannot bulk load because the file could not be opened. Operating system error code 5(Access is denied.).

I originally implemented all this on SQL Server 2005 and at that time, the directory structure was on a SQL Server 2005 box.  The NT authenticated service account login had no problem accessing the individual files.  However, when it became necessary to relocate the directory structure off of the database server, the service account could no longer access the files.  I managed to resolve this issue by doing the following;

1. I submitted a request for new SQL Server authenticated login.
2. I changed the connection string in my application to utilize the new login (instead of integrated security.)
3. I asked my DBA to give me the name of the service account that was running the SQL Server engine.  With that, I submitted another request to give that service account read/write access to the directory structure containing the downloaded files.

Here is the reasoning.  If an application connects to a server while using a NT authenticated login, when SQL Server reaches out for the file to be imported, it will do so with those credentials.  SQL server appears to be losing the NT authenticated security context and therefore cannot access the files.  However, when the application connects with an SQL Server authenticated login, SQL Server reaches out with it's own security context (the service account that is running SQL server.)  In this case, the security context is not lost and the files are successfully imported because that service account was granted sufficient access to the directory structure. 

As this constitutes a double hop scenario, the credentials of the executed application, if using integrated security in the database connection string should be the same credentials used to both connect to SQL server (hop 1 from the application server) and access the directory structure (hop 2 from the database server.)  A few others in this company have dealt with this situation the same way.  To date, I have not heard of the causes of these double hop failures, nor have I dug deep enough to attempt a lower level resolution.  We simply employ this alternative instead.  I would be happy to hear from anyone that has taken the time to understand the causes and or has implemented a solution.