September 8, 2004 at 9:49 pm
Hi there, I am upgrading our SQL 2000 box which currently runs Windows 2000 to a Windows 2003 server.
The problem I have is that the DTS I need to run as a job gives an error message saying " Error string: The system cannot find the path specified." The Job runs with a SQL Login with sa rights. The Agent runs with a Domain Admin login as the service account with a SQL Login in the connection tab to connect to the SQL Server.
It is trying to run a bat file from a Network drive which works on our 2000 server but will not on the new 2003 server. The DTS runs manually.
I have checked security is the same between the two boxes the only difference that we can see is that one is 2000 Server and the New one is 2003.
Any suggestions would be appreciated.
Thanks
Angie
September 10, 2004 at 3:11 am
As with all debugging, the most likely thing is that the error message is telling you the truth. The most likely cause is that one of the file paths used by your DTS does not exist on your W2003 box. The next most likely cause is that your DTS does not have the NT authorities needed to access the file.
A good way to debug this could be
1) find all the file paths used by your DTS
2) change your .bat file to run a DIR command for each file path.
3) Make sure you run everything using the same authorities as your real DTS job. If a DIR does not work you can start looking for the cause.
We have hit similar problems a few times during upgrades. Many of them have been due to share names not being created on the new box, or spelt slightly differently. Other common cause is NT security preventing the user from accessing the domain resource from the new box. All of these are easy to fix when you know what the exact problem is.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 12, 2004 at 9:58 pm
Thanks for the reply,
I have actually checked all that. I have taken out the paths and re-entered them, we have switch from NT Authentication user to a SQL User to run the job. I can navigate to the file in question via the mapped drives in the DTS and Explorer.
We have even taken the DTSRUN syntax out of the job and run that from a command prompt, it worked..... just won't work as a scheduled job.
This is frustrating...... !!!!
Angie
September 13, 2004 at 8:11 pm
Is the Microsoft Distributed Transaction Coordinator (MSDTC service) started and set to do auto start?
September 13, 2004 at 8:21 pm
Thanks for the reply,
Yes it is started and set to auto start at startup......
This is driving me crazy
September 14, 2004 at 12:55 pm
We just ran into this same problem last week. Windows 2003 comes with MDAC 2.8. You need to apply a hotfix for 2.8. See article at http://support.microsoft.com/default.aspx?scid=kb;en-us;839801
After the hotfix was applied all the jobs worked!
September 15, 2004 at 8:31 pm
Thanks for the reply, could you tell me which hotfix you applied as there are a number listed for the page... and they do not really seem to match the error we are getting.
Cheers
Angie
September 16, 2004 at 4:25 am
Check the location of the DTS Package on the new server. Th elocation should be identical to what is specified in the job step
September 16, 2004 at 7:28 am
We applied FullInstalVer = 2.80.1048.0 as it seemed to be the most recent, but after we applied it we found it wasn't the most recent, though it still resolved the job error, but MS should be able to tell you the version that is.
LS
September 21, 2004 at 9:49 pm
Thanks for the help but that did not work either ........ Even my Network Guys can't figure it out......
Is there some security issue with Windows 2003 server and SQL Server 2000 ?
I'm beat.....
September 28, 2004 at 5:19 pm
Well, have worked out with the help of one of our Domain System Admin guys that the mapped drives we had would not work under Windows 2003 Server.
This is because the server was logged in with an NT user that was already using the drive mappings and the SQL Agent runs the process as the same NTuser but as another session, which then could not gain access to that users mapped drives because it was already being used.
So we had to Create an NT user for SQL Agent that was different to what the box (server) was logged on as, take the drive mappings away from that Login and add them to the new login. Or leave the server logged off.
Our jobs then started working.
The info that gave us the tip is as below. FYI
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply