AustinSeven
asked on
ODBC connection string does not recognise DNS alias
In some of our Excel workbooks with external data queries to SQL Server 2000 setup, the connection string for the table is:
ODBC;DRIVER=SQL Server;SERVER=SQL1;UID=Fre
The above worked ok until we renamed the SQL1 instance to something else (eg. SQLServer) and introduced a DNS alias called 'SQL1'. All other apps connect ok using the new DNS alias, 'SQL1'. However, since the change, some spreadsheets with external data queries have been failing with the message:
[Microsoft][ODBC SQL Server Driver][SQL Server] Could not find server 'SQL1' in sysservers. Execute sp_addlinedserver to add the server to sysservers
It's of course true that 'SQL1' isn't in syservers because the server was renamed to something else. However, the new DNS alias 'SQL1' points to what used to be the SQL1 SQL Server instance (eg. 'SQLServer'). It appears to be that ODBC isn't attempting to find the server via DNS.
For now, we are working around the problem by changing the connection strings not to use the 'SQL1' DNS alias but we prefer to use the alias (eg. easier DR failover). Can someone tell me if this can be fixed so that these spreadsheet connections to SQL Server use the DNS alias?
AustinSeven
ODBC;DRIVER=SQL Server;SERVER=SQL1;UID=Fre
The above worked ok until we renamed the SQL1 instance to something else (eg. SQLServer) and introduced a DNS alias called 'SQL1'. All other apps connect ok using the new DNS alias, 'SQL1'. However, since the change, some spreadsheets with external data queries have been failing with the message:
[Microsoft][ODBC SQL Server Driver][SQL Server] Could not find server 'SQL1' in sysservers. Execute sp_addlinedserver to add the server to sysservers
It's of course true that 'SQL1' isn't in syservers because the server was renamed to something else. However, the new DNS alias 'SQL1' points to what used to be the SQL1 SQL Server instance (eg. 'SQLServer'). It appears to be that ODBC isn't attempting to find the server via DNS.
For now, we are working around the problem by changing the connection strings not to use the 'SQL1' DNS alias but we prefer to use the alias (eg. easier DR failover). Can someone tell me if this can be fixed so that these spreadsheet connections to SQL Server use the DNS alias?
AustinSeven
James Murrell
have you read http://support.microsoft.com/kb/827422
here's what's happening:
the DNS alias "SQL1" will get you to the IP address for the new server, "SQLServer"
however, once you hit the server, ODBC/Excel is selecting things from the server named "SQL1" which obviously doesn't exist.
one way to fix this is to update the servername
sp_dropserver 'SQL1'
sp_addlinkedserver ....
check for sp_addlinkedserver and sp_dropserver in Books Online. Also, if you are ever going to "rename a SQL Server", check Google for the correct steps to do it. you need to update system tables as well.
the DNS alias "SQL1" will get you to the IP address for the new server, "SQLServer"
however, once you hit the server, ODBC/Excel is selecting things from the server named "SQL1" which obviously doesn't exist.
one way to fix this is to update the servername
sp_dropserver 'SQL1'
sp_addlinkedserver ....
check for sp_addlinkedserver and sp_dropserver in Books Online. Also, if you are ever going to "rename a SQL Server", check Google for the correct steps to do it. you need to update system tables as well.
for moving sql server this is a must read http://support.microsoft.com/default.aspx?scid=KB;EN-US;q224071&
ASKER
cs97jjm3,
Thanks for the link although I couldn't find anything about this particular problem.
imitchie,
I already had done the usual sp_dropserver 'SQL1', sp_addlinkedserver stuff as part of the server rename. That isn't the issue. The server rename was done correctly and all apps connect properly. Sysservers contains references to the new server name as expected. The issue is that ODBC connection strings from excel don't pickup the DNS alias. Maybe there's a parameter that can be inserted into an ODBC connection string to make it reference DNS. Not sure.
AustinSeven
Thanks for the link although I couldn't find anything about this particular problem.
imitchie,
I already had done the usual sp_dropserver 'SQL1', sp_addlinkedserver stuff as part of the server rename. That isn't the issue. The server rename was done correctly and all apps connect properly. Sysservers contains references to the new server name as expected. The issue is that ODBC connection strings from excel don't pickup the DNS alias. Maybe there's a parameter that can be inserted into an ODBC connection string to make it reference DNS. Not sure.
AustinSeven
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
imitchie,
>This reference to sysservers comes from SQL Server, so I'm 100% positive that it has in fact resolved >the DNS name. You just need to create a SQL alias to SQL1 in sysservers (link name = SQL1, target = >actual server) to make Excel/ODBC work
You're right, I see that now thank you. I added a new Linked Server called 'SQL1' aliased to the actual name of the server and the offending spreadsheets connected ok (no need for dropping any server in sysservers). I don't fully understand this yet but it appears that the ODBC Jet Driver looks down the list of 'servers' in sysservers until it finds the name referenced in the connection string. However, I thought that the ODBC Jet Driver would just try to connect to the target SQL server and not try to match the SERVER parameter in the connection string with entries in SYSSERVERS... After all, it has already connected to the requried server as you pointed out so why bother doing this? It just seems like a redundant step that causes problems.
Thanks,
AustinSeven
>This reference to sysservers comes from SQL Server, so I'm 100% positive that it has in fact resolved >the DNS name. You just need to create a SQL alias to SQL1 in sysservers (link name = SQL1, target = >actual server) to make Excel/ODBC work
You're right, I see that now thank you. I added a new Linked Server called 'SQL1' aliased to the actual name of the server and the offending spreadsheets connected ok (no need for dropping any server in sysservers). I don't fully understand this yet but it appears that the ODBC Jet Driver looks down the list of 'servers' in sysservers until it finds the name referenced in the connection string. However, I thought that the ODBC Jet Driver would just try to connect to the target SQL server and not try to match the SERVER parameter in the connection string with entries in SYSSERVERS... After all, it has already connected to the requried server as you pointed out so why bother doing this? It just seems like a redundant step that causes problems.
Thanks,
AustinSeven