Blog Post

SQL Server Blog
3 MIN READ

SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified

SQL-Server-Team's avatar
Mar 23, 2019
First published on MSDN on May 13, 2007

Users often see this error message when connection to a SQL Server and don't know where to start to solve the problem. In most forums, people says this is because remote connection is not enabled on the server. This is not exactly correct. Actually, this error message give customers very specific information and the solution is quite simple.

First of all, you get this error message only if you are trying to connect to a SQL Server named instance. For default instance, you never see this. Why? Because even if we failed at this stage (i.e. error locating server/instance specified), we will continue to try connect using default values, e.g defaul TCP port 1433, default pipe name for Named Pipes. You may see other error message due to failure later, but not this error message.

Every time client makes a connection to SQL Server named instance, we will send a SSRP UDP packet to the server machine UDP port 1434. We need this step to know configuration information of the SQL instance, e.g., protocols enabled, TCP port, pipe name etc. Without these information, client does know how to connect the server and it fails with this specified error message.

In a word, the reason that we get this error message is the client stack could not receive SSRP response UDP packet from SQL Browser. It's easy to isolate the issue. Here are the steps:
1) Make sure your server name is correct, e.g., no typo on the name.
2) Make sure your instance name is correct and there is actually such an instance on your target machine. [Update: Some application converts \ to . If you are not sure about your application, please try both ServerInstance and Server\Instance in your connection string ]
3) Make sure the server machine is reachable, e.g, DNS can be resolve correctly, you are able to ping the server (not always true).
4) Make sure SQL Browser service is running on the server.
5) If firewall is enabled on the server, you need to put sqlbrowser.exe and/or UDP port 1434 into exception.

Once you are done the steps, you should not see this error message anymore. You may still fail to connect your SQL server, but error message should be different and you have a different issue now. [ Update: If it still fails, you may replace serverinstance with tcp:serverinstance and/or np:serverinstance and see if it succeeds with either TCP or NP protocol. That way, you can isolate the issue a little bit. ]

There is one corner case where you may still fail after you checked step 1)-4). It happens when a) your server is a named instance on cluster or on a multi-homed machine, and b) your client is a Vista machine with Firewall on. I have explained the details at: Unable to connect to a SQL Server named instance on a cluster

[ Update May 2009 ] My collegue found a good tool online which could be very helpful for users to isolate issues related to this error message. You can download PortQry from http://support.microsoft.com/kb/832919 , run "portqry.exe -n yourservername -p UDP -e 1434". If this command returns information and it contains your target instance, then you can rule out possiblity 4) and 5) above, meaning you do have a SQL Browser running and your firewall does not block SQL Browser UDP packet. In this case, you can check other issue, e.g. wrong connection string.

As a final note, the error message for the same issue when you use SNAC is:
[SQL Native Client]SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].

If you still see this error, please post questions at MSDN SQL Server Data Access Forum:
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=87&SiteID=1
Please mention you already read this post and confirm steps you have taken and the results of each step.(e.g. serverinstance,etc)

Xinwei Hong, SQL Server Protocols
Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights


Updated Mar 23, 2019
Version 2.0
No CommentsBe the first to comment