Failing Job

Question

Failing Job

ehlinger

Hall of Fame

Points: 3585
More actions
March 29, 2006 at 9:24 am

#111508

I have a package that was set up to pull information out of an Access database that has security on it. This has given me the pleasure of having to work again with Access' workgroup files. Anyway, I have the package set up and it is running fine because I've pointed the Access connection to the mdw file for the workgroup.
My issues is occurring in the job that I have created to run the package. It fails everytime with the following error:
[WorkDoc].[dbo].[tbl_Work] Step DTSRun OnError: Copy Data from tbl Work to [WorkDoc].[dbo].[tbl_Work] Step, Error = -2147217843 (80040E4D) Error string: Cannot start your application. The workgroup information file is missing or opened exclusively by another user. Error source: Microsoft JET Database Engine Help file: Help context: 5003028 Error Detail Records: Error: -2147217843 (80040E4D); Provider Error: -124520301 (F893F893) Error string: Cannot start your application. The workgroup information file is missing or opened exclusively by another user. Error source: Microsoft JET Database Engine Help file: Help context: 5003028 DTSRun OnFinish: Copy Data from tbl Work to [WorkDoc].[dbo].[tb. The step failed.
I was getting this same type of thing (Cannot start your application. The workgroup information file is missing or opened exclusively by another user.) in the package until I pointed it to the mdw file.
Any ideas on what I have to do in order to get the job to run this package that is working fine when invoked manually?

Viewing 3 posts - 1 through 2 (of 2 total)

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

SQLBill SSC Guru Points: 51440 More actions · Answer 1

One thing to look into is permissions. When you run a command manually, it is running using your login. When you run it as a job, it is running with the login for SQL Server Agent service.

-SQLBill

ehlinger Hall of Fame Points: 3585 More actions · Answer 2

Thanks. In looking at the permissions on the server where the mdb file resides, the login for SQL Server Agent service didn't have rights to it. Once we added rights to that server\directory it seems to be working fine... for now anyway.