July 16, 2002 at 3:34 am
Executing a package manually works fine, but scheduling the package fails on .GetFolder I guess due to the unc name for the folder.
The full error message is at the end of this post.
NT4 & SQL Server 7.0
strFolder=DTSGlobalVariables("strUploadDirectory").value
set objFSO=CreateObject("Scripting.FileSystemObject")
set objFolder=objFSO.GetFolder(strFolder)
The global variable points to a share on our SAN in the form \\999.999.999.999\d$
I can't map a drive on the sql server machine and the file has to be at a network location.
Any ideas?
-------------------------------------------
DTSRun: Loading... DTSRun: Executing... DTSRun OnStart: DTSStep_DTSActiveScriptTask_1 DTSRun OnError: DTSStep_DTSActiveScriptTask_1, Error = -2147220482 (800403FE) Error string: Error Code: 0
Error Source= Microsoft VBScript runtime error
Error Description: Path not found
Error on Line 35
Error source: Microsoft Data Transformation Services (DTS) Package
Help file: sqldts.hlp Help context: 1100 Error Detail Records: Error: -2147220482 (800403FE); Provider Error: 0 (0) Error string: Error Code: 0 Error Source= Microsoft VBScript runtime error Error Description: Path not found Error on Line 35 Error source: Microsoft Data Transformation Services (DTS) Package Help file: sqldts.hlp Help context: 1100 DTSRun OnFinish: DTSStep_DTSActiveScriptTask_1 DTSRun: Package execution complete. Process Exit Code 1. The step failed.
July 16, 2002 at 6:08 am
This problem usually comes from SQL Server Agent running under local system account on the box or an account without access to the remote path. If you have a domain or local account for SQL Agent then try logging in as that account on the SQL box to see if you can connect to the remote share. If not then you need to get the permissions to the remote share corrected.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
July 16, 2002 at 9:58 am
I can't access the sql box because it is a virtual cluster in a secure location. The ip address that is used to access sql server doesn't point to a real server - merely to a cluster. For this reason I have to access sql server remotely. So 'going' to the server and running the package is not an option.
As to SQL Agent. The microsoft knowledge base mentions that packages owned by a login that is not a member of the sysadmin server role are '... run under the context of the SQLAgentCmdExec account and has the rights and permissions of that account.' The package is owned by my local domain account so I guess the rights are defaulted to SQLAgentCmdExec.
I don't recognise SQLAgentCmdExec - has anyone had dealings with this account?
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply