Tuve el mismo problema con la instancia con nombre instalada localmente de SQL Server 2014. Conectar usando el FQDN\InstanceNamefallaría, mientras que conectando usando solo mi hostname\InstanceNametrabajo. Por ejemplo: conectarse usando mycomputername\sql2014trabajado, pero usandomycomputername.mydomain.org\sql2014 no. DNS se resolvió correctamente, TCP / IP se habilitó en el Administrador de configuración de SQL, se agregaron las reglas del Firewall de Windows (y luego se apagó el firewall para realizar pruebas para asegurarse de que no estaba bloqueando nada), pero ninguno solucionó el problema.
Finalmente, tuve que iniciar el servicio " Navegador de SQL Server " en SQL Server y eso solucionó el problema de conectividad.
Nunca me había dado cuenta de que el servicio del navegador SQL Server realmente ayudaba al servidor SQL a hacer conexiones; Tenía la impresión de que simplemente ayudó a llenar los menús desplegables cuando hizo clic en "buscar más" servidores para conectarse, pero en realidad ayuda a alinear las solicitudes de los clientes con el puerto correcto para usar, si el puerto no está asignado explícitamente (similar sobre cómo los enlaces a sitios web ayudan a aliviar el mismo problema en un servidor web IIS que aloja varios sitios web).
Este elemento de conexión es lo que me dio la pista sobre el servicio del navegador SQL Server: https://connect.microsoft.com/SQLServer/feedback/details/589901/unable-to-connect-on-localhost-using-fqdn-machine- nombre
- cuando usa wstst05 \ sqlexpress como nombre del servidor, el código del cliente separa el nombre de la máquina del nombre de la instancia y wstst05 se compara con el nombre de netbios. No veo ningún problema para que coincidan y la conexión se considera local. A partir de ahí, recuperamos la información necesaria SIN contactar al Navegador SQL y nos conectamos a la instancia SQL a través de la Memoria Compartida sin ningún problema.
- cuando usa wstst05.capatest.local \ sqlexpress, el código del cliente falla la comparación del nombre (wstst05.capatest.local) con el nombre de netbios (wstst05) y considera la conexión "remota". Esto es por diseño y definitivamente consideraremos mejorar esto en el futuro. De todos modos, debido a que considera la conexión remota y al hecho de que es una instancia con nombre, el cliente decide que necesita usar SQLBrowser para la resolución de nombres. Intenta ponerse en contacto con el navegador SQL en wstst05.capatest.local (puerto UDP 1434) y aparentemente esa parte falla. De ahí el error que obtienes.
La razón del servicio "Navegador SQL Server" de TechNet (énfasis agregado por mí): https://technet.microsoft.com/en-us/library/ms181087(v=sql.120).aspx
Desde la sección "Uso del navegador SQL Server":
Si el servicio del navegador SQL Server no se está ejecutando, aún puede conectarse a SQL Server si proporciona el número de puerto correcto o la canalización con nombre. Por ejemplo, puede conectarse a la instancia predeterminada de SQL Server con TCP / IP si se está ejecutando en el puerto 1433. Sin embargo, si el servicio del navegador SQL Server no se está ejecutando, las siguientes conexiones no funcionan :
- Cualquier componente que intente conectarse a una instancia con nombre sin especificar completamente todos los parámetros (como el puerto TCP / IP o la tubería con nombre) .
- Cualquier componente que genere o pase información de servidor \ instancia que luego otros componentes puedan usar para volver a conectarse.
- Conectarse a una instancia con nombre sin proporcionar el número de puerto o tubería.
- DAC a una instancia con nombre o la instancia predeterminada si no usa el puerto TCP / IP 1433.
- El servicio de redireccionador OLAP.
- Enumeración de servidores en SQL Server Management Studio, Enterprise Manager o Query Analyzer.
Si está utilizando SQL Server en un escenario cliente-servidor (por ejemplo, cuando su aplicación accede a SQL Server a través de una red), si detiene o deshabilita el servicio del navegador SQL Server, debe asignar un número de puerto específico a cada instancia y escriba su código de aplicación de cliente para usar siempre ese número de puerto. Este enfoque tiene los siguientes problemas :
- Debe actualizar y mantener el código de la aplicación del cliente para asegurarse de que se está conectando al puerto adecuado.
- El puerto que elija para cada instancia puede ser utilizado por otro servicio o aplicación en el servidor, lo que hace que la instancia de SQL Server no esté disponible.
Y más información del mismo artículo de la sección "Cómo funciona el navegador SQL Server":
Porque solo una instancia de SQL Server puede usar un puerto o tubería, se asignan diferentes números de puerto y nombres de canalización para instancias con nombre, incluido SQL Server Express. De manera predeterminada, cuando está habilitado, tanto las instancias con nombre como SQL Server Express están configuradas para usar puertos dinámicos, es decir, se asigna un puerto disponible cuando se inicia SQL Server. Si lo desea, se puede asignar un puerto específico a una instancia de SQL Server. Al conectarse, los clientes pueden especificar un puerto específico; pero si el puerto se asigna dinámicamente, el número de puerto puede cambiar cada vez que se reinicia SQL Server, por lo que el cliente desconoce el número de puerto correcto. ... Cuando los clientes de SQL Server solicitan recursos de SQL Server, la biblioteca de red del cliente envía un mensaje UDP al servidor utilizando el puerto 1434. El navegador SQL Server responde con el puerto TCP / IP o canalización con nombre de la instancia solicitada.
