When you try to connect to a local instance, SQL Server will always attempt to use Shared Memory. This connection will work fine:
localhost\SQL2012
This works in my scenario, and the connection is indeed using Shared Memory in this case.
SELECT session_id,net_transport,local_net_address,local_tcp_port
FROM sys.dm_exec_connections;
Results:
session_id net_transport local_net_address local_tcp_port
---------- ------------- ----------------- --------------
53 Shared memory <local machine> NULL
If you want to try to override Shared Memory (not sure why, on a local machine) and force TCP/IP instead, you can't mix that with specifying the named instance explicitly, at least in all instances I tried (no pun intended). The named instance forces SQL Server to map the instance name to the port number, using SQL Server browser, but this apparently can't be done when you force TCP/IP in the first place (the whole point of using TCP/IP is so you go straight to the port and not bother with the browser). If your named instance happens to be running on its own IP address and forced to port 1433, you may be able to get this to work; you may also be able to get it to work if you are using a Client Network alias (but I could not).
I was able to connect if I looked up the current dynamic port assigned to that instance in Configuration Manager (in my case it was 49538), and then connect using tcp:localhost,49538
:
So now:
SELECT session_id,net_transport,local_net_address,local_tcp_port
FROM sys.dm_exec_connections;
Results:
session_id net_transport local_net_address local_tcp_port
---------- ------------- ----------------- --------------
53 Shared memory <local machine> NULL
54 TCP 10.211.55.10 49538
All variations I tried - across multiple machines and versions - where I tried to combine a named instance with overriding shared memory and use TCP/IP instead - yielded the same error that you received. This is both when I prefixed the server/instance name with tcp:
and when I specified TCP/IP for the network protocol in the connection properties dialog.
Long story short: If you really need to force TCP/IP for a local connection, you're going to need to use a fixed port for that instance, and specify the port. Or use 1433 (which will only work if there's no default instance or if you have a dedicated IP address for that instance), then you won't need to specify the port, but you'll still need to specify the tcp:
prefix or use that option in the connection dialog.
I do not suggest trying to disable Shared Memory. FWIW.
(local)
or127.0.0.1
orMSWART7
or the actual IP address instead oflocalhost
, does anything change? What network protocols are enabled in Configuration Manager? (I don't know that you can specifytcp:
successfully when using a named instance name, which implies Shared Memory. I can't connect on any of mine that way - I either need to usetcp:
with a port, or notcp:
with a name.)(local)
,127.0.0.1
andMSWART7
don't change the behavior of what I'm seeing. Thetcp:
prefix seems consistent with the alternative method of specifying the protocol in the Connection Properties.sys.dm_exec_connections
is also a useful dmvtcp:
for a named instance while also naming the instance. The point of specifyingtcp:
is that you go directly to the port instead of relying on the browser service to map instance name -> port. What happens when you don't use thetcp:
prefix?localhost\instance
and specify TCP/IP in the Connection Properties, either. IMHO you're mixing two things by specifying the instance name and trying to force TCP. If you want to force TCP for a named instance, you're going to have to specify a fixed port in the service configuration, and specify that port # when connecting. Or use a client network utility alias maybe. For local connections it will attempt to use Shared Memory unless you specify otherwise; named instance isn't specifying otherwise :-).)