Legacy SQLOLEDB/DBNETLIB clients cannot reach a Shared-Memory-only SQL Server; Data Source=lpc:<MachineName> works

Symptom

A 32-bit legacy tool (a backup/restore engine built on the MDAC-era SQLOLEDB provider) "did nothing": it printed its banner, exited with -1 or 0 and gave no error. Nothing appeared in the SQL Server errorlog, not even a failed login. Everything else on the same machine connected fine (sqlcmd -S localhost -E, SSMS, .NET), so connectivity looked healthy and suspicion fell on the tool or its licensing.

Cause

The instance had only the Shared Memory protocol enabled. The note describes this as the default of a fresh Developer or Express install (TCP/IP and Named Pipes off). Modern drivers (MSOLEDBSQL, ODBC 17/18, SqlClient) connect through shared memory when given localhost, . or the host name. SQLOLEDB, which goes through DBNETLIB, did not. A probe with System.Data.OleDb gave:

| Data Source | SQLOLEDB | MSOLEDBSQL | |---|---|---| | localhost | [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied | connects | | . or the host name | Login timeout expired | connects | | tcp:localhost,1433 | fails (TCP disabled) | fails | | lpc:<MachineName> | connects | connects |

A failed connect (as opposed to a failed login) never reaches the server, which is why the errorlog stays empty.

Fix

Give the legacy client the explicit shared-memory prefix: Data Source=lpc:<MachineName>, or the tool's own server switch with the same value (for example -S lpc:<MachineName>). Enabling TCP/IP or Named Pipes in SQL Server Configuration Manager and restarting the service also works, but lpc: needs no server change.

Reproducing the tool's own provider

Testing with a modern driver hides the problem. The note's diagnostic is to loop a connection test over the candidate server names and over the providers SQLOLEDB, MSOLEDBSQL and SQLNCLI11:

# For a 32-bit tool, run this from the 32-bit PowerShell (SysWOW64)
$c = New-Object System.Data.OleDb.OleDbConnection 'Provider=SQLOLEDB;Data Source=localhost;Integrated Security=SSPI;Connect Timeout=5'
$c.Open(); $c.ServerVersion

The provider a binary uses can be found by scanning its bytes as UTF-16 for SQLOLEDB, SQLNCLI or MSOLEDBSQL.

Unverified

• The result table comes from one SQL Server 2022 instance. Other versions and the effect of enabling Named Pipes only were not tested.
• The lpc: prefix is documented for the SQL Server client protocols; this note only records that it fixed the legacy provider here.