SQL SERVER – Fix Connection Error – [Microsoft][ODBC SQL Server Driver][DBNETLIB][ConnectionOpen(Connect())

A client’s application hit a connection error on a named instance. Ping worked. Telnet to the port worked. Connecting by server and port worked. Only connecting by server and instance name failed. That combination points at one thing, and I rebuilt it on SQL Server 2025 so you can see exactly what is going on underneath.

The Error and What Worked

[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()).

This is how the old SQL Server ODBC driver said “I could not reach it”. It tells you nothing more. So we worked through it on the call:

ping SQLMACHINE                  works
telnet SQLMACHINE 2433           works
connect to SQLMACHINE,2433       works
connect to SQLMACHINE\INSTANCE   fails

The server is up, the port is open, and SQL Server accepts logins on it. The only thing the failing connection does differently is ask for the instance by name.

How a Name Becomes a Port

A named instance does not live on 1433. It gets its own port, often a random one. The client has no idea what that port is. So before it connects, it asks the SQL Server Browser service, over UDP port 1434, “which port is this instance on?”

You can ask the Browser the same question yourself. This PowerShell sends the request a driver sends and prints the answer:

$u = New-Object System.Net.Sockets.UdpClient
$u.Client.ReceiveTimeout = 3000
$u.Connect('SQLMACHINE', 1434)
$req = [byte[]](@(4) + [Text.Encoding]::ASCII.GetBytes('SQLDEV') + @(0))
[void]$u.Send($req, $req.Length)
$ep = New-Object System.Net.IPEndPoint([Net.IPAddress]::Any, 0)
$r = $u.Receive([ref]$ep)
[Text.Encoding]::ASCII.GetString($r, 3, $r.Length - 3)
$u.Close()

On my machine it came back with this:

ServerName;SQLBOX;InstanceName;SQLDEV;IsClustered;No;Version;17.0.1000.7;tcp;1455;np;\\SQLBOX\pipe\MSSQL$SQLDEV\sql\query;;

tcp;1455 is the whole answer. The driver reads that and connects to port 1455. If that UDP reply never arrives, the driver never learns the port, and connecting by name fails while connecting by port carries on working. That is exactly the pattern my client had.

A small side note from the same reply. It says version 17.0.1000.7, but my instance is on a later cumulative update. The Browser reports the base version, not the patch level. Do not use this reply to check what an instance is patched to.

Why Telnet Lied

Telnet tests TCP. The Browser answers on UDP. A firewall rule that allows TCP 2433 and says nothing about UDP 1434 passes the telnet test and blocks the name lookup. So the one tool everyone reaches for gives a green light on the half that was never broken.

The PowerShell above is the test for the other half. Run it from the client machine, not the server. No reply within three seconds and you have found it.

What the Failures Look Like Today

I timed four connections with the current ODBC driver. Two good ones, and two deliberately wrong:

tcp:localhost\SQLDEV             223 ms    TCP port 1455
tcp:localhost,1455               206 ms    TCP port 1455
tcp:localhost\NOSUCHINSTANCE   21237 ms    Error Locating Server/Instance Specified
tcp:localhost,1499             21654 ms    TCP Provider: The wait operation timed out

The two failures are worth learning to tell apart. Error Locating Server/Instance Specified means the name lookup failed: the Browser is not running, UDP 1434 is blocked, or the instance name is wrong. The wait operation timed out means the port lookup was skipped or succeeded, and the TCP connection itself went nowhere.

About those twenty-one seconds: that is my own setting, not SQL Server’s. I ran the test with a 20-second login timeout, and both failures used all of it. The lesson is the other way round. An application with a short connection timeout can give up before the driver has an error to report, and all you see is “timeout”. If you are chasing this error, lengthen the timeout while you test, so the real message has time to arrive.

Do Not Test on the Server

This one caught me while I was writing this. The first connection I tried, from the server itself, was to .\SQLDEV. It connected in 237 milliseconds. Then I checked what it had actually used:

SELECT net_transport, local_tcp_port
FROM   sys.dm_exec_connections
WHERE  session_id = @@SPID;

Shared memory    NULL

Shared memory. No network, no Browser, no port, no firewall. A local connection proves only that SQL Server is running. Put tcp: in front of the name, or better, test from the machine that is actually failing.

Three Fixes, Best First

Open UDP 1434 on the firewall between the client and the server, and make sure the SQL Server Browser service is running and set to start automatically. That fixes the cause.

Give the instance a fixed port in SQL Server Configuration Manager, under the TCP/IP properties. A dynamic port can change after a restart, and a fixed one lets you write firewall rules that stay true.

Connect by port, or create a client alias that maps the name to the port. This is what we did on the call to get the application working that afternoon. It works, but every new client machine needs the same alias, and it quietly breaks if the port ever changes. Treat it as the bandage, not the cure.

This error is not SQL Server refusing you, it is a question on UDP 1434 that never got an answer.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.