J'ai eu le même problème avec l'instance nommée installée localement SQL Server 2014. La connexion en utilisant le FQDN\InstanceNameéchouerait, tandis que la connexion en utilisant uniquement mon hostname\InstanceNametravail. Par exemple: se connecter en utilisant mycomputername\sql2014travaillé, mais en utilisantmycomputername.mydomain.org\sql2014 non. DNS résolu correctement, TCP / IP a été activé dans SQL Configuration Manager, des règles de pare-feu Windows ont été ajoutées (puis ont désactivé le pare-feu pour les tests afin de s'assurer qu'il ne bloquait rien), mais aucune de celles-ci n'a résolu le problème.
Enfin, j'ai dû démarrer le service " SQL Server Browser " sur SQL Server et cela a résolu le problème de connectivité.
Je n'avais jamais réalisé que le service SQL Server Browser aidait réellement SQL Server à établir des connexions; J'avais l'impression que cela a simplement aidé à remplir les listes déroulantes lorsque vous avez cliqué sur "Parcourir pour plus" de serveurs auxquels vous connecter, mais cela aide en fait à aligner les demandes des clients sur le bon port # à utiliser, si le port # n'est pas explicitement attribué (similaire comment les liaisons de sites Web aident à atténuer le même problème sur un serveur Web IIS qui héberge plusieurs sites Web).
Cet élément de connexion est ce qui m'a donné l'indice sur le service SQL Server Browser: https://connect.microsoft.com/SQLServer/feedback/details/589901/unable-to-connect-on-localhost-using-fqdn-machine- Nom
- lorsque vous utilisez wstst05 \ sqlexpress comme nom de serveur, le code client sépare le nom de la machine du nom de l'instance et le wstst05 est comparé au nom netbios. Je ne vois aucun problème pour eux et la connexion est considérée comme locale. À partir de là, nous récupérons les informations nécessaires SANS contacter le navigateur SQL et nous nous connectons à l'instance SQL via la mémoire partagée sans aucun problème.
- lorsque vous utilisez wstst05.capatest.local \ sqlexpress, le code client échoue la comparaison du nom (wstst05.capatest.local) avec le nom netbios (wstst05) et considère la connexion "distante". C'est par conception et nous envisagerons certainement d'améliorer cela à l'avenir. Quoi qu'il en soit, compte tenu de la connexion distante et du fait qu'il s'agit d'une instance nommée, le client décide qu'il doit utiliser SQLBrowser pour la résolution de noms. Il tente de contacter le navigateur SQL sur wstst05.capatest.local (port UDP 1434) et apparemment cette partie échoue. D'où l'erreur que vous obtenez.
La raison du service "SQL Server Browser" de TechNet (emphase ajoutée par moi): https://technet.microsoft.com/en-us/library/ms181087(v=sql.120).aspx
Dans la section "Utilisation du navigateur SQL Server":
Si le service SQL Server Browser n'est pas en cours d'exécution, vous pouvez toujours vous connecter à SQL Server si vous fournissez le numéro de port correct ou le canal nommé. Par exemple, vous pouvez vous connecter à l'instance par défaut de SQL Server avec TCP / IP si elle s'exécute sur le port 1433. Cependant, si le service SQL Server Browser n'est pas en cours d'exécution, les connexions suivantes ne fonctionnent pas :
- Tout composant qui tente de se connecter à une instance nommée sans spécifier entièrement tous les paramètres (comme le port TCP / IP ou le canal nommé) .
- Tout composant qui génère ou transmet des informations de serveur \ instance qui pourraient ensuite être utilisées par d'autres composants pour se reconnecter.
- Connexion à une instance nommée sans fournir le numéro de port ou le canal.
- DAC vers une instance nommée ou l'instance par défaut si vous n'utilisez pas le port TCP / IP 1433.
- Le service de redirection OLAP.
- Énumération des serveurs dans SQL Server Management Studio, Enterprise Manager ou Query Analyzer.
Si vous utilisez SQL Server dans un scénario client-serveur (par exemple, lorsque votre application accède à SQL Server via un réseau), si vous arrêtez ou désactivez le service SQL Server Browser, vous devez attribuer un numéro de port spécifique à chaque instance et écrivez votre code d'application client pour toujours utiliser ce numéro de port. Cette approche présente les problèmes suivants :
- Vous devez mettre à jour et maintenir le code de l'application client pour vous assurer qu'il se connecte au port approprié.
- Le port que vous choisissez pour chaque instance peut être utilisé par un autre service ou application sur le serveur, entraînant l'indisponibilité de l'instance de SQL Server.
Et plus d'informations dans le même article de la section "Fonctionnement du navigateur SQL Server":
Parce que qu'une seule instance de SQL Server peut utiliser un port ou un canal, différents numéros de port et noms de canal sont attribués pour les instances nommées, y compris SQL Server Express. Par défaut, lorsqu'il est activé, les instances nommées et SQL Server Express sont configurés pour utiliser des ports dynamiques, c'est-à-dire qu'un port disponible est attribué au démarrage de SQL Server. Si vous le souhaitez, un port spécifique peut être attribué à une instance de SQL Server. Lors de la connexion, les clients peuvent spécifier un port spécifique; mais si le port est attribué dynamiquement, le numéro de port peut changer à chaque redémarrage de SQL Server, de sorte que le numéro de port correct est inconnu du client. ... Lorsque les clients SQL Server demandent des ressources SQL Server, la bibliothèque réseau client envoie un message UDP au serveur à l'aide du port 1434. Le navigateur SQL Server répond avec le port TCP / IP ou le canal nommé de l'instance demandée.
