January 12, 2015 at 9:48 am
In the interests of full disclosure I posted this in the DTS forum Friday, but haven't gotten any replies. I fear that is an inactive forum so am reposting here.
I have a DTS package that is run overnight from an Agent job and on request from a stored procedure. Both use dtsrun (SQL Server 2005). They have both worked for years, but have suddenly stopped. The package itself can be executed successfully from the package designer window. I know that the network administrator password was changed at about the same time the failures started. Does dtsrun somehow use that password in the background? In the dtsrun run call the sa user and password are supplied, but that hasn't changed. If helpful the unencryped Agent job step looks like:
DTSRun /S "(local)" /N "Abramover" /E /!X /!C
though I think the last 2 are left over from the decrypting.
The sp call looks like:
exec master..xp_cmdshell 'dtsrun /Sbell-sql32 /nabramover /Usa /Ppassword '
I'd appreciate if somebody could point this non-DBA struggling to get things working again in the right direction. I feel like it has to be that network admin password, but I can't see where it would be used.
January 16, 2015 at 11:45 am
To follow up, it turns out that the network administrator had changed the login account used by the SQL Server services from Administrator to Local System. Changing the Agent service back allows it to run successfully.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply