September 23, 2004 at 10:34 am
Hello,
I have a DTS ETL package running on SQL Server 2000 Enterprise SP3 on a four processor, 8GB RAM Windows Server 2003 Enterprise Edition box with AWE enabled. In this package I use an ActiveX task object to open a text file via the File System Object and read the data into a staging table. For some reason the filesystemobject can no longer access the shared drive it was pointed to. This package has worked reliably for a few years now prior to yesterday.
Additionally, in windows explorer I can not access the same shared drive that the filesystemobject in the ActiveX script is failing to access. Nor can I access any shared drives on the same server that the filesystemobject is now unable to access. I can however access shared drives on every other server in the network from the box that the DTS package is running on.
Both the SQLServerAgent service and the SQL Server itself are running under a Domain account with proper permissions to the folder and shared drive in question.
Anyone ever come across something like this before? Any suggestions would be greatly appreciated.
Thank you,
Michael
mhweiss
September 23, 2004 at 2:05 pm
We were able to resolve the issue. It was a WINS configuration problem that for some mysterious reason took about twenty days to show up in the network. Go figure...
Anyway, thanks to all who took a moment to look at the issue and think about it...
Michael
mhweiss
September 29, 2004 at 4:22 pm
Hi there, we had a similar problems with our SQL Server 2000 on a Windows 2003 Server.
We had mapped drives that some of our dts packages ran to inparticular a batch file. This would run as a dts but not as a job and also another dts that copied tables from an access database on a mapped drive.
We found these two white papers below invaluable. The reason being that on Windows 2003 Server the SQL Agent runs in another session mode, so if you logon with an NT account and the drives are mapped, if the same account is used in the Agent the job will fail as the mapped drive is in use. We got around this by taking the mapped drives away from the server login and creating an new NT login for the agent and mapping the drives for that login.
You can run most DTS Packages with a unc path then as they run under the context of the server login, but Batch jobs, we have found, need the net use drive and cd to the drive letter in them to work.
eg.net use g: \\servername\directoryname
g:
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply