Re: DTS editing errors after porting to different server
- From: Scott.Ashby@xxxxxxxx
- Date: Sun, 13 Jan 2008 19:45:13 -0800 (PST)
On Jan 11, 9:55 am, Scott.As...@xxxxxxxx wrote:
Everyone,
I am in the process of porting some DTS packages from SQL Server 2000
Enterprise Edition (x86), SP3a, running on Windows 2003 Server
Enterprise Edition (NO SERVICE PACK) to a new SQL Server 2000
Enterprise Edition (x86), SP3a server running on Windows 2003 Server
Enterprise Edition Service Pack 2. I was able to put together a DTS
package to bring these over, and when I executed it, it worked just
fine - The packages appeared as expected on the new server.
However, am having some difficulty editing the packages. For
instance, when I edit a simple package from within Enterprise Manager
while actually logged onto the server that contains 2 connections and
a data pump task, and I try to view the properties on the data pump
task, I get the following Package Error dialog:
Error Source: Microsoft OLEDB Provider for SQL Server
Error Description: Login failed for user '(null)'. Reason: Not
associated with a trusted SQL server connection.
The connections in the package are currently set to use Windows
authentication. If I change them to use a known standard login, the
error disappears, so I think it has something to do with Windows
Authentication.
I've seen similar problems when the Service Principal Name for a
service is not properly defined on the SQL Service account, but I have
verified that the SPN is in place.
On the source server, I have no problems editing packages. The only
other significant difference in the servers is the OS service pack
level. Is this causing the problem, possibly? I remember when we
first put SP1 on the source server, DTS started failing, so we rolled
it back... That's why we don't have the service pack on the source
server.
Thanks,
Scott Ashby
DBA
Swedish Match North America
This is an update (more specifics with my problem). I tested whether
it was OS Service Pack related by removing Windows Server 2003 Service
Pack 2, and
it most definitely was related. After this, I was able to edit the
DTS packages, no problem.
Also, an additional wrinkle: We make use of entries in host files to
assist in code portability between dev, test and prod environments
(for example, an
entry in %windir%\System32\drivers\etc\hosts for HOSTA might point to
different servers in each environment). My DTS editing problem occurs
specifically
in the packages that make use of these host entries as the server
names of the connections in the package. Also, if I change the
connections to use SQL
authentication instead of Windows authentication, it works...
Anybody else seen anything like this?
Scott
.
- References:
- DTS editing errors after porting to different server
- From: Scott . Ashby
- DTS editing errors after porting to different server
- Prev by Date: running ssis from sql server
- Next by Date: RE: How to 'Keep Identity' On?
- Previous by thread: DTS editing errors after porting to different server
- Next by thread: Re: To copy files from a folder to another folder
- Index(es):
Relevant Pages
|
