August 16, 2007 at 9:29 am
Hello, this problem has be going nuts. For the life of me I can't seem to get an Integration Services job to run... AT ALL. I've tried migrating it from an old DTS 2000 package as well as having built it completely from scratch in Visual Studio. It doesn't matter... as soon as I try to create a job to run it automatically, I get this error:
Executed as user: <Domain>\svcreporting. ...00.3042.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 10:09:00 AM Error: 2007-08-16 10:09:03.28 Code: 0xC002F325 Source: Copy DefaultTenant Transfer SQL Server Objects Task Description: Execution failed with the following error: "The directory 'LocalApplicationData' does not exist.". End Error Error: 2007-08-16 10:09:03.71 Code: 0xC002F325 Source: TSupportCAD Transfer SQL Server Objects Task Description: Execution failed with the following error: "The directory 'LocalApplicationData' does not exist.". End Error Error: 2007-08-16 10:09:03.72 Code: 0xC002F325 Source: Copy Teamshare Data Transfer SQL Server Objects Task Description: Execution failed with the following error: "The directory 'LocalApplicationData' does not exist.". End Error Error: 2007-08-16 10:09:05.10 Code: 0xC002F325 Source: Copy Application Transfer SQL Serve... The package execution fa... The step failed.
Why the heck does this always happen? I can't seem to find any information on how to fix it. All that I have been able to gather is that this is supposed to be referring to the local user's special directory (c:\documents and settings\<user>\local settings\application data) as established by .Net. Has anyone heard of this and offer advice on what I should be doing to resolve it? This is completely roadblocking our attempt to use SQL 2005 in a test environment prior to deploying it. Thanks!
Brian
August 16, 2007 at 2:21 pm
Brian,
Is this merely a single task control flow package, or is there more involved? The error you posted looks like the error from the job, rather than an SSIS execution error detail.
Does the package run in BIDS? Are there any package variables looking in the mentioned directory?
One thing you can try is when you're in BIDS, do CTRL-Shift-F and search for "LocalApplicationData". That should give you a clue as to what object in the package is giving you the problems.
Hope this helps!
Dan
August 16, 2007 at 3:18 pm
Thanks for the input Dan. The SSIS package consists of 4 Transfer SQL Server Objects Tasks. These tasks are not joined by any success/failure/completion constraint. They all run simultaneously. Two of the task objects connect to seperate databases on one source server while the other two task objects connect to seperate databases on a second source server. The source servers are both running SQL Server 2000. What I'm trying to do is copy a select few tables from each of the 4 databases (on 2 servers) into one destination server and 4 different databases. This really should be something very simple, and indeed our old DTS 2000 package that runs this on our live server has no problems at all. But for some reason no matter what I try, I keep getting errors when doing this under SSIS.
To answer your other questions, yes the tasks do run fine when I test them individually in Visual Studio. The problem only seems to come in when I import my package into SQL 2005 and setup a scheduled job for that package to run. I import the package into SQL 2005 IS using the security level of letting SQL Server roles / users manage security. I then configure the job to run it and set a test schedule a couple minutes ahead of current time. The job kicks off and within 3 seconds usually it fails and dumps out with the message in the original post.
I tried searching my IS package from Visual Stuido using the method you suggested and it did not find any reference at all to "LocalApplicationData". I searched the entire solution. I know I've never specified anything like that either as I built it. It seems to be some weird generic system generated error than anything specific.
August 17, 2007 at 6:25 am
Ok, I'll take a stab at this. Log into the server with the credentials your job agent is running under and try to execute the package without the job agent. The error may be due to the windows account the job agent is running under not having enough permissions or simply never having a profile set up on the server.
Also, SQL 2005 installs pretty locked down. Transfer DB objects jobs tend to use script files and bulk inserts, so the job agent will need to be able to get to the file system. Make sure all of your permissions are configured correctly.
August 17, 2007 at 3:01 pm
This may not be relevant but when I set up a job to run a package I had to specify folder addresses from the point of view of the server not from the client.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply