Post reply

Failing Job

  • 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? 

  • March 29, 2006 at 10:20 am

    #629578

    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

  • March 29, 2006 at 11:15 am

    #629599

    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.

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

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