There seems to be a subtle incompatibility issue. We have started moving our
SQL 2000 servers to 32-bit OS's on virtual machines to avoid the issue.
But if anyone knows of a simpler fix we could implement, I would love to
hear it.
Thanks,
Tim C
> SQL 2005 SP2 on Windows Server 2003 SP2
> SQL 2000 SP4 on Windows Server 2003 SP2, with SQL 2005 Native Client installed
[quoted text clipped - 20 lines]
> Thanks,
> Tim C
Tibor Karaszi - 09 Mar 2008 09:29 GMT
I recently had a discussion in .tools about this. Paul O'kasick was nice enough to share his
findings. Aparently there's both a 32 and a 64 bit version of cliconfg.exe and these modify
different registry keys. Here's a quote from Paul most recent reply:
"The alias is working on our test machine. It turns out there is a 64 bit
version of cliconfg.exe (C:\WINDOWS\SysWOW64\cliconfg.exe). As soon as I
created the alias with that version, the application started working. I
removed the alias created with the 32 bit version.
Each version maintains a separate list of aliases. The registry key for the
32 bit vs. 64 bit is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo &
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo,
respectively."
So, my suggestion is that you try to create the alias with both 32 and 64 bit version of
cliconfg.exe to see which it is that is required in your particular case (probably depends on
whether the client app is 32 or 64 bit - meguess).

Signature
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
> There seems to be a subtle incompatibility issue. We have started moving our
> SQL 2000 servers to 32-bit OS's on virtual machines to avoid the issue.
[quoted text clipped - 29 lines]
>> Thanks,
>> Tim C