Tras revisar una charla que Gert Drappers impartió en TechEd 2004 en Amsterdam, me puse a hacer unas pruebas con cadenas de conexiones preparando un Taller MSDN que impartí esta mañana en Valencia llegando a un resultado “extraño” del que comparto mis conclusiones:
Sea el método Connect como sigue:
Private Sub Connect(ByVal server As String)
Dim s As String = “Server=” + server + “;Database=Northwind;Trusted_Connection=SSPI;Application Name=” + server + “;Pooling=false;”
Dim con As New SqlConnection(s)
Try
con.Open()
Console.WriteLine(“ok ; ” + server)
con.Close()
Catch ex As Exception
Console.WriteLine(“Error; ” + server + vbTab + ex.Message)
End Try
End Sub
Y las siguientes peticiones de conexión:
Connect(“lpc:localhost”)
Connect(“localhost”)
Connect(“np:localhost”)
Connect(“localhost”)
Connect(“tcp:localhost”)
Connect(“localhost”)
He deshabilitado “Connection Pooling” para que SQL Server Profiler me caze todas las peticiones de conexión;
Pues bien, los resultados que me ha dado Profiler han sido los siguientes:
Audit Login — network protocol: TCP/IP lpc:localhost 53
Audit Login — network protocol: TCP/IP localhost 53
Audit Login — network protocol: Named Pipes np:localhost 53
Audit Login — network protocol: Named Pipes localhost 53
Audit Login — network protocol: TCP/IP tcp:localhost 53
Audit Login — network protocol: TCP/IP localhost 53
Donde las columnas representan EventClass, TextData, Application Name y SPID.
Llegando a la siguiente conclusión:
Cada vez que conectas con nombre de servidor localhost, independientemente del protocolo de conexión especificado, SQL Server conectará con el protocolo anteriormente usado para nombre de servidor localhost; en caso de que no haya sido utilizado ninguno (en el registro de windows no hay información de cuál fué el protocolo anteriormente usado) conectará con protocolo TCP/IP.
Por si os interesa, he utilizado la utilidad Regmon de sysinternals que muestra los accesos realizados al registro de windows.
http://www.sysinternals.com/ntw2k/source/regmon.shtml
La entrada del registro que guarda cual fué el ultimo protocolo de conexión utilizado es:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSSQLServerClientSuperSocketNetLibLastConnect
Y la recomendación sería la siguiente:
Utiliza como nombre de servidor en conexiones a la máquina Local: (local), . (punto) o el nombre del servidor.
Define en tu cadena de conexión el protocolo de conexión a utilizar; en el fondo es sencillo; anteponer al nombre del servidor el protocolo de conexión seguido de dos puntos:
np para Named Pipes,
tcp para TCP/IP y
lpc para Shared Memory (memoria compartida).
Notas:
el comportamiento no se reproduce en .NET Framework 2.0 🙂
si el nombre del servidor es (local) o . (punto) y no se especifica protocolo de conexión, el funcionamiento es el esperado; conectará por Shared Memory.
Otra nota (para los asistentes a la sesión de MSDN en Valencia):
El comentario que hice sobre el comportamiento de peticiones de conexión con localhost no fué correcto; os dije que cuando conectamos con nombre de servidor localhost, independientemente del protocolo de conexión especificado la conexión SIEMPRE se realizaría con TCP/IP; siento haberme expresado erroneamente … y nos vemos en la próxima !!!! 🙂
comentadme que opináis sobre este comportamiento ...
