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 ...
0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like

UNPIVOT “SINCRONO”

Más de una vez nos hemos encontrado en la situación de tener que unpivotar una tabla, teniendo así que recurrir o bien al componente “Unpivot” de SSIS o incluso a tener que guardar los datos en tabla y realizar posteriormente una lectura de esta misma utilizando T-SQL para unpivotarla, con los problemas que ambas soluciones nos puedan conllevar con un gran volumen de datos.
Leer más

Calculate Groups en SSAS Tabular 2019

Hace unos meses se lanzó al público SQL Server 2019 Analysis Services CTP 2.3. Esta nueva versión trae una nueva funcionalidad para los modelos tabulares, los calculate groups. Los calculate groups vienen a hacernos la vida un poco más fácil a la hora de desarrollar modelos tabulares, dando la opción de reutilizar métricas, como pueden ser por ejemplo, las relacionadas con el tiempo.
Leer más

Aplicando seguridad a métricas SSAS

Aplicando seguridad a métricas SSAS. Para controlar la seguridad de los objetos, operaciones y datos de Analysis Services se utilizan roles (grupos de usuarios). Los usuarios se pueden añadir o quitar de los roles y para esos roles se determinan unos permisos.