August 23, 2005 at 12:12 pm
I have a repository package that just executes an in-house created .exe. I can run the package without a problem but when I schedule a job for it it always fails. A couple of weeks ago it worked fine but now fails even after I recreated the job. Here is the error it is producing:
DTSRun: Loading... DTSRun: Executing... DTSRun OnStart: DTSStep_DTSCreateProcessTask_1 DTSRun OnError: DTSStep_DTSCreateProcessTask_1, Error = -2147024784 (80070070) Error string: There is not enough space on the disk. Error source: Microsoft Data Transformation Services (DTS) Package Help file: sqldts.hlp Help context: 1100 Error Detail Records: Error: -2147024784 (80070070); Provider Error: 0 (0) Error string: There is not enough space on the disk. Error source: Microsoft Data Transformation Services (DTS) Package Help file: sqldts.hlp Help context: 1100 DTSRun OnFinish: DTSStep_DTSCreateProcessTask_1 DTSRun: Package execution complete. Process Exit Code 1. The step failed.
I've checked the servers and there seems to be more than enough disk space. I must be missing something simple I'm sure. Any help or a point in the right direction would be great. Thanks.
August 23, 2005 at 12:20 pm
Do you have quotas in place??
August 23, 2005 at 1:17 pm
Could be a permission problem. You have no problem running it under the sql server agent account?
August 23, 2005 at 1:51 pm
I'm sorry Remi, I'm not sure what you are referring to when you talk about quotas.
Jo, I don't think it is a permission problem but it could be. I have no problem when I execute the package itself, only when I attempt to execute the job. Both the package and job were created directly on the server under the sa login.
August 23, 2005 at 1:55 pm
You can find the quota info on the hd itself using windows explorer. That tells windows to keep X % or X MB of free space on the drive. If the limit is met then windows acts as if the drive was full.
August 23, 2005 at 2:33 pm
Not finding any issues with the permissions and I've looked for the quota information but haven't found anything so I'm having some of our IT guys look at that.
So to sum up, if I just execute the package it runs. If I just execute the exe itself outside of SQL it runs. It only fails when I attempt to have a scheduled job run it for us.
August 23, 2005 at 2:38 pm
Under what account is the agent running?
August 23, 2005 at 2:50 pm
When looking at the SQL Server connection it is using Windows Authentication. Could that be the problem? We've got roughly 60 other jobs on this server and don't have a problem with any of them. There is at least one other one that is basically the same as this, it runs an executable. The only difference is we pass it a command line parameter.
August 24, 2005 at 5:44 am
I would right click the SQL Agent service under control panel services and check which windows account the agent is running under. Log into the pc as this account (the one the agent runs under) and try run the exe - if it fails its the account, if it works its got to be something else.
Right click the job \ view job history \ click details - does this give any clues as to the reason for failure?
August 24, 2005 at 9:14 am
Logging into the server under the same account as the SQL Agent runs the exe. The details of the job history are with the original post. It indicates not being enough disc space but there is pleanty on the servers. I also found out from our IT department that we haven't instituted quotas.
August 25, 2005 at 2:35 am
Sorry - missed the error on your first post.
What about this disc filling up at night and clearing space again: e.g. large transaction logs filling up the disc and truncating later when you back up your databases - So the disc is full at the time your job tries to run but is cleared again by the time you check in the morning. Just a thought.
August 25, 2005 at 8:18 am
Thought about that but when we run the job manually during the day we get the exact same error.
August 25, 2005 at 5:21 pm
I'd be willing to bet that you're looking at the wrong disk. If you've developed the DTS package on your local machine and specified the path as "X:\my_folder\my_file.txt", and it runs ok, then fails when scheduled, its because the context under which the package is running can't see YOUR X:\... . Its looking for ITS X:\... , which may not even exist. Change your path to a UNC path, such as \\MY_Server\C$\my_folder\my_file.txt or any other UNC share, and it'll probably work.
Steve
August 26, 2005 at 7:23 am
Checked that already. I'm using UNC share. It just doesn't make any sense.
August 26, 2005 at 12:37 pm
Does the id that runs the job have rights to the share?
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply