A network-related or instance-specific error occurred while establishing a connection to SQL Server

S’applique à :   SQL Server

Lors de la connexion à une instance SQL Server, vous pouvez rencontrer un ou plusieurs des messages d’erreur ci-dessous. Cet article fournit quelques étapes pour vous aider à résoudre ces erreurs, qui sont fournies dans l’ordre des problèmes simples à complexes.

Messages d’erreur

Les messages d’erreur complets varient en fonction de la bibliothèque cliente utilisée dans l’application et l’environnement serveur. Vous pouvez consulter les détails suivants pour voir si vous rencontrez l’un des messages d’erreur suivants :

provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server (Microsoft SQL Server, Error: 53) Une erreur liée au réseau ou spécifique à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance.
provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server (Microsoft SQL Server, Error: 53)
fournisseur : Fournisseur TCP, erreur : 0 - Aucun hôte de ce type n’est connu. (Microsoft SQL Server, Erreur : 11001)

provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified Une erreur liée au réseau ou spécifique à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance.
provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified

Expiration du délai d’expiration de la connexion Erreur de liaison de données SQL Server Native Client
[Microsoft SQL Server Native Client 10.0]: Login timeout expired
[Microsoft SQL Server Native Client 10.0]: A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.
[Microsoft SQL Server Native Client 10.0]: SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].

Échec d’une tentative de connexion, car la partie connectée n’a pas répondu correctement après un certain temps, ou la connexion établie a échoué, car l’hôte connecté n’a pas répondu Une erreur liée au réseau ou spécifique à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance.
fournisseur : Fournisseur TCP, erreur : 0
Une tentative de connexion a échoué, car la partie connectée n’a pas répondu correctement après un certain temps, ou la connexion établie a échoué, car l’hôte connecté n’a pas répondu.
Microsoft SQL Server, Erreur : 10060

fournisseur : Fournisseur de canaux nommé, erreur : 40 - Impossible d’ouvrir une connexion à SQL Server Une erreur liée au réseau ou spécifique à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance.
fournisseur : Fournisseur de canaux nommé, erreur : 40 - Impossible d’ouvrir une connexion à SQL Server
Microsoft SQL Server, Erreur : 53
Le chemin d’accès réseau est introuvable

[Microsoft] [SQL Server Native Client 11.0]Fournisseur TCP : Aucune connexion n’a pu être établie, car l’ordinateur cible l’a refusée activement Erreur de liaison de données SQL Server Native Client
[Microsoft] [SQL Server Native Client 11.0]Fournisseur TCP : Aucune connexion n’a pu être établie, car l’ordinateur cible l’a refusée activement.
[Microsoft] [SQL Server Native Client 11.0]Expiration du délai de connexion.
[Microsoft] [SQL Server Native Client 11.0]Une erreur liée au réseau ou spécifique à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez si le nom de l’instance est correct et si SQL Server est configuré pour autoriser les connexions à distance. Pour plus d’informations, consultez SQL Server livres en ligne.

« SQL Server n’existe pas ou l’accès n’est pas refusé »

Cette erreur signifie généralement que le client ne trouve pas l’instance SQL Server. Ce problème se produit lorsqu’au moins l’un des problèmes suivants existe :

  • Le nom de l’ordinateur hébergeant SQL Server est incorrect.
  • L’instance ne résout pas l’adresse IP correcte.
  • Le numéro de port TCP n’est pas spécifié correctement.

Notes

Pour résoudre les problèmes de connectivité dans les scénarios de haute disponibilité, consultez les articles suivants :

Collecter des informations pour résoudre l’erreur

Nous vous recommandons de collecter les informations répertoriées dans cette section à l’aide de l’une des options ci-dessous avant de poursuivre les étapes réelles pour résoudre l’erreur.

Option 1 : Utiliser l’outil VÉRIFICATION SQL pour collecter les informations requises

Si vous pouvez vous connecter localement à l’ordinateur SQL Server et disposer d’un accès administrateur, utilisez SQLCheck à partir du référentiel GitHub microsoft SQL Networking. Cet outil fournit la plupart des informations requises pour la résolution des problèmes dans un seul fichier. Consultez la page d’accueil de l’outil pour plus d’informations sur l’utilisation de l’outil et les informations qu’il collecte. Vous pouvez également vérifier les prérequis recommandés et la page de liste de vérification.

Option 2 : Collecter les données individuellement à l’aide des procédures suivantes

Obtenir le nom de l’instance à partir de Configuration Manager

Sur le serveur qui héberge l’instance de SQL Server, utilisez Gestionnaire de configuration SQL Server pour vérifier le nom de l’instance :

Notes

Configuration Manager est automatiquement installé sur l’ordinateur lorsque SQL Server est installé. Les instructions de démarrage Configuration Manager varient légèrement selon les versions de SQL Server et Windows. Pour plus d’informations sur la version, consultez Gestionnaire de configuration SQL Server.

  1. Connectez-vous à l’ordinateur hébergeant l’instance de SQL Server.

  2. Démarrez Gestionnaire de configuration SQL Server.

  3. Dans le volet gauche, sélectionnez SQL Server Services.

  4. Dans le volet droit, vérifiez le nom de l’instance du moteur de base de données.

    • SQL SERVER (MSSQLSERVER) indique une instance par défaut de SQL Server. Le nom de l’instance par défaut est <computer name>.
    • SQL SERVER (<instance name>) indique une instance nommée de SQL Server. Le nom de l’instance nommée est <computer name>\<instance name>.

Obtenir l’adresse IP du serveur

Vous pouvez utiliser les étapes suivantes pour obtenir l’adresse IP de l’ordinateur hébergeant l’instance de SQL Server.

  1. Dans le menu Démarrer , sélectionnez Exécuter. Dans la fenêtre Exécuter , tapez cmd, puis sélectionnez OK.

  2. Dans la fenêtre d’invite de commandes , tapez ipconfig/all , puis appuyez sur Entrée. Notez l’adresse IPv4 et l’adresse IPv6.

    Notes

    SQL Server pouvez vous connecter à l’aide du protocole IP version 4 ou IP version 6. Votre réseau peut autoriser l’une ou les deux.

Obtenir le port TCP de l’instance

Dans la plupart des cas, vous vous connectez au moteur de base de données sur un autre ordinateur à l’aide du protocole TCP. Pour obtenir le port TCP de l’instance, procédez comme suit :

  1. Utilisez SQL Server Management Studio sur l’ordinateur exécutant SQL Server et connectez-vous à l’instance de SQL Server. Dans Explorateur d'objets, développez Gestion, développez SQL Server journaux, puis double-cliquez sur le journal actuel.

  2. Dans la visionneuse de fichiers journaux, sélectionnez Filtrer dans la barre d’outils. Dans la zone de texte du message , tapez que le serveur écoute, sélectionnez Appliquer le filtre, puis sélectionnez OK.

  3. Un message tel que Server est à l’écoute sur [ « any » <ipv4> 1433] doit être répertorié.

    Ce message indique que l’instance de SQL Server écoute sur toutes les adresses IP de cet ordinateur (pour la version IP 4) et sur le port TCP 1433. (Le port TCP 1433 est généralement le port utilisé par le moteur de base de données ou l’instance par défaut de SQL Server. Une seule instance de SQL Server peut utiliser ce port. Si plusieurs instances de SQL Server sont installées, certaines instances doivent utiliser d’autres numéros de port.) Notez le numéro de port utilisé par l’instance SQL Server à laquelle vous essayez de vous connecter.

    Notes

    • L’adresse IP 127.0.0.1 est probablement répertoriée. Il s’agit de l’adresse de l’adaptateur de bouclage. Seuls les processus sur le même ordinateur peuvent utiliser l’adresse IP pour se connecter.
    • Vous pouvez également afficher le SQL Server journal des erreurs à l’aide d’un éditeur de texte. Par défaut, le journal des erreurs se trouve dans les fichiers Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG et ERRORLOG.n. Pour plus d’informations, consultez l’affichage du journal des erreurs SQL Server.

Étape 1 : Vérifier que l’instance est en cours d’exécution

Option 1 : Utilisation du fichier de sortie de l’outil SQLCheck

  1. Recherchez « SQL Server Informations » dans la sortie du fichier SQLCheck.

  2. Dans la section intitulée « Services d’intérêt », recherchez votre instance SQL Server sous les colonnes Nom et Instance (pour les instances nommées) et vérifiez son état à l’aide de la colonne Démarrée. Si la valeur est True, les services sont démarrés. Sinon, le service n’est pas en cours d’exécution.

  3. Si le service n’est pas en cours d’exécution, démarrez le service à l’aide de SQL Server management Studio, SQL Server Configuration Manager, PowerShell ou Services applet.

Option 2 : Utiliser Gestionnaire de configuration SQL Server

Pour vérifier que l’instance est en cours d’exécution, sélectionnez SQL Server Services dans Gestionnaire de configuration SQL Server et vérifiez le symbole par l’instance SQL Server.

  • Une flèche verte indique qu’une instance est en cours d’exécution.
  • Un carré rouge indique qu’une instance est arrêtée.

Si l’instance est arrêtée, cliquez avec le bouton droit sur l’instance et sélectionnez Démarrer. Ensuite, l’instance de serveur démarre et l’indicateur devient une flèche verte.

Option 3 : Utiliser des commandes PowerShell

Vous pouvez utiliser la commande suivante dans PowerShell pour vérifier l’état des services SQL Server sur le système :

Get-Service | Where {$_.status -eq 'running' -and $_.DisplayName -match "sql server*"}

Vous pouvez utiliser la commande suivante pour rechercher la chaîne spécifique « SQL Server est maintenant prête pour les connexions clientes dans le fichier journal des erreurs. Il s’agit d’un message d’information; aucune action de l’utilisateur n’est requise. » :

Get-ChildItem -Path "c:\program files\microsoft sql server\mssql*" -Recurse -Include Errorlog |select-string "SQL Server is now ready for client connections."

Étape 2 : Vérifier que le service SQL Server Browser est en cours d’exécution

Notes

Cette étape est requise uniquement pour résoudre les problèmes de connectivité avec des instances nommées.

Option 1 : Utilisation du fichier de sortie à partir de l’outil SQLCheck

  1. Recherchez « SQL Server Informations » dans la sortie du fichier SQLCheck.

  2. Dans la section intitulée « Services d’intérêt », recherchez SQLBrowser dans la colonne Nom et vérifiez son état à l’aide de la colonne Démarrée . Si la valeur est True, le service est démarré. Sinon, le service n’est pas en cours d’exécution et vous devez le démarrer. Pour plus d’informations, consultez Démarrer, arrêter, suspendre, reprendre, redémarrer SQL Server services.

Option 2 : Utiliser Gestionnaire de configuration SQL Server

Pour se connecter à une instance nommée, le service SQL Server Browser doit être en cours d’exécution. Dans Gestionnaire de configuration SQL Server, recherchez le service SQL Server Browser et vérifiez qu’il est en cours d’exécution. S’il n’est pas en cours d’exécution, démarrez le service. Le service SQL Server Browser n’est pas requis pour les instances par défaut.

Pour plus d’informations sur l’utilisation du service SQL Server Browser dans votre environnement, consultez SQL Server Service Browser.

Pour plus d’informations sur l’arrêt et le démarrage de SQL Services, consultez Démarrer, arrêter, suspendre, reprendre, redémarrer SQL Server services.

Notes

Si le service SQL Server Browser n’est pas en cours d’exécution dans votre environnement, consultez Connexion à l’instance nommée SQL Server sans SQL Server service de navigateur.

Étape 3 : Vérifier le nom du serveur dans la chaîne de connexion

Vous rencontrez souvent des erreurs lorsqu’un nom de serveur incorrect est spécifié dans la chaîne de connexion. Assurez-vous que le nom du serveur correspond à celui que vous avez récupéré dans les étapes précédentes.

Notes

Si vous utilisez l’outil SQLCheck, passez en revue les valeurs nom/nom de domaine complet NetBios dans la section Informations sur l’ordinateur du fichier de sortie.

Étape 4 : Vérifier les alias sur les machines clientes

Les alias sont souvent utilisés dans les environnements clients lorsque vous vous connectez à SQL Server avec un autre nom ou en cas de problèmes de résolution de noms dans le réseau. Ils sont créés à l’aide de Gestionnaire de configuration SQL Server ou de l’utilitaire de réseau client. Un alias incorrect peut entraîner la connexion de vos applications au serveur incorrect, ce qui entraîne un échec. Utilisez les méthodes suivantes pour rechercher des alias incorrects. Vous pouvez également utiliser un outil (tel que SQLCHECK) sur l’ordinateur client pour rechercher des alias et divers autres paramètres liés à la connectivité sur un ordinateur client.

Notes

Les options suivantes s’appliquent uniquement aux applications qui utilisent SQL Server Native Client pour se connecter à SQL Server.

Option 1 : Utilisation du fichier de sortie de l’outil SQLCheck

  1. Dans le fichier de sortie SQLCheck, recherchez les alias SQL de chaîne. (Cette chaîne se trouve à l’intérieur de la section Informations sur la sécurité du client et le pilote du fichier)

  2. Passez en revue les entrées de la table. S’il n’y en a aucun, il n’y a pas d’alias sur l’ordinateur. S’il existe une entrée, passez en revue les informations pour vous assurer que le nom du serveur et le numéro de port sont définis sur les valeurs correctes.

Exemple de sortie :
Alias SQL :

Alias Name   Protocol   Server Name     Port   32-bit 

----------   --------   ------------    ----   ------ 

prodsql      TCP        prod_sqlserver  1430      

Ce qui précède indique qu’il prodsql s’agit d’un alias pour un SQL Server appelé prod_sqlserver qui s’exécute sur le port 1430.

Option 2 : Vérifier les alias dans Gestionnaire de configuration SQL Server

  1. Dans Gestionnaire de configuration SQL Server, développez SQL Server Native Client Configuration, puis sélectionnez Alias.
  2. Vérifiez si des alias sont définis pour le serveur auquel vous essayez de vous connecter. Si les alias existent, procédez comme suit :
    1. Ouvrez le volet Propriétés de l’alias.
    2. Renommez la valeur dans le champ Nom de l’alias (par exemple, si votre nom de serveur est MySQL, renommez-la en tant que MySQL_test) et réessayez la connexion. Si la connexion fonctionne, votre alias est incorrect et peut provenir d’une ancienne configuration qui n’est plus nécessaire. Si la connexion ne fonctionne pas, renommez l’alias en son nom d’origine et passez à l’étape suivante.
    3. Vérifiez les paramètres de connexion de l’alias et assurez-vous qu’ils sont corrects. Les scénarios courants suivants peuvent entraîner des problèmes de connectivité :
      • Adresse IP incorrecte pour le champ Serveur . Assurez-vous que l’adresse IP correspond à l’entrée dans le fichier journal des erreurs SQL Server.

      • Nom de serveur incorrect dans le champ Serveur . Par exemple, votre alias de serveur pointe vers le nom de serveur approprié. Toutefois, les connexions échouent si la valeur du paramètre de nom de serveur est incorrecte.

      • Format de nom de canal incorrect (en supposant que vous utilisez un alias de canaux nommé).

        • Lors de la connexion à une instance par défaut nommée Mydefaultinstance, le nom du canal doit être \\Mydefaultinstance\pipe\sql\query.
        • Lors de la connexion à une instance nommée MySQL\Named, le nom du canal doit être \\MySQL\pipe\MSSQL$Named\sql\query.

Option 3 : Vérifier les alias dans SQL Server’utilitaire réseau client

  1. Ouvrez SQL Server utilitaire réseau client en tapant cliconfg.exe dans votre commande Exécuter.
  2. Suivez l’étape 2 de l’option 2 : Vérifiez les alias dans Gestionnaire de configuration SQL Server.

Étape 5 : Vérifier la configuration du pare-feu

Vous pouvez vérifier la configuration du pare-feu en fonction de l’instance par défaut ou de l’instance nommée.

Notes

Si vous utilisez des pare-feu tiers dans votre réseau, les concepts s’appliquent toujours. Toutefois, vous devrez peut-être travailler avec votre administrateur réseau ou consulter la documentation du produit de pare-feu pour plus d’informations sur la configuration du pare-feu afin d’autoriser les ports nécessaires à la communication avec SQL Server.

Instance par défaut de SQL Server

Une instance par défaut s’exécute généralement sur le port 1433. Certaines installations utilisent également un port non standard (autre que 1433) pour exécuter des instances SQL. Le pare-feu peut bloquer l’un ou l’autre des ports. Pour vérifier le numéro de port, procédez comme suit :

  1. Déterminez le port sur lequel votre instance SQL s’exécute. Consultez Obtenir le port TCP de l’instance.
  • Si votre SQL Server est configuré pour écouter sur le port 1433, assurez-vous que les pare-feu sur le réseau entre le client et le serveur autorisent le trafic sur ce port. Consultez Configurer un pare-feu Windows pour l’accès au moteur de base de données et collaborez avec votre administrateur réseau pour implémenter les solutions nécessaires.

  • Si votre SQL Server instance par défaut n’utilise pas 1433, essayez d’ajouter le numéro de port de SQL Server au nom du serveur en utilisant le format <servername>,<portnumber> et de voir si elle fonctionne. Par exemple, le nom de votre instance SQL est MySQLDefaultinstance et s’exécute sur le port 2000. Spécifiez le nom de serveur MySQLServer, 2000 , et vérifiez si cela fonctionne.

  • Si cela ne fonctionne pas, cela indique que le pare-feu bloque le port. Vous pouvez suivre les instructions de configuration d’un pare-feu Windows pour l’accès au moteur de base de données ou collaborer avec votre administrateur réseau pour ajouter le port à la liste d’exclusion du pare-feu.

    • Si cela fonctionne, cela indique que le pare-feu autorise la communication via ce port. Vous devez modifier votre chaîne de connexion afin d’utiliser le numéro de port et le nom de votre serveur dans la chaîne de connexion de votre application.

Instance nommée de SQL Server

Si votre instance SQL est une instance nommée, elle peut être configurée pour utiliser des ports dynamiques ou un port statique. Dans les deux cas, les bibliothèques réseau sous-jacentes interrogent le service SQL Server Browser s’exécutant sur votre machine SQL Server via le port UDP 1434 pour énumérer le numéro de port de l’instance nommée. Si un pare-feu entre le client et le serveur bloque ce port UDP, la bibliothèque cliente ne peut pas déterminer le port (une exigence de connexion) et la connexion échoue. Pour vérifier la connexion, vous pouvez utiliser l’une des méthodes suivantes :

  • Méthode 1 : Vérifiez la connexion en spécifiant le numéro de port dans votre chaîne de connexion.

    1. Déterminez le port sur lequel votre instance SQL s’exécute. Consultez Obtenir le port TCP de l’instance.

    2. Essayez de vous connecter à l’instance nommée en utilisant le numéro de port ajouté au nom du serveur au format <servername\instancename>,<portnumber> et vérifiez si cela fonctionne. Par exemple, si votre nom d’instance SQL est MySQL\Namedinstance et qu’il s’exécute sur le port 3000, spécifiez le nom du serveur MySQL\Namedinstance,3000.

      • Si cela fonctionne, cela indique que le pare-feu bloque le port UDP 1434 ou que l’instance est masquée dans SQL Server Browser.

      • S’il ne fonctionne pas, il indique l’une des situations suivantes :

        • Le port UDP 1434 est bloqué ou le port statique est bloqué, ou les deux. Pour vérifier s’il s’agit du port UDP ou du port statique, utilisez Portqry.

        • L’instance est masquée du service SQL Server Browser.

  • Méthode 2 : Vérifiez la connexion à l’aide de l’outil PortQryUI.

    Utilisez l’outil PortQryUI avec votre instance nommée et observez la sortie obtenue. Vous pouvez voir un message indiquant que le port UDP 1434 est filtré. Ce message indique que le port est bloqué sur le réseau. Pour obtenir des instructions sur l’utilisation de l’outil, consultez Utilisation de l’outil PortQryUI avec SQL Server.

    Déterminez si l’instance SQL Server écoute sur des ports dynamiques ou statiques. Utilisez ensuite la méthode suivante qui est pertinente pour votre scénario. Si vous n’êtes pas sûr, consultez Comment vérifier si SQL Server écoute sur un port dynamique ou un port statique.

    • Scénario 1 : Ports dynamiques. Dans ce cas, vérifiez que le service SQL Server Browser est démarré et que le port UDP 1434 n’est pas bloqué sur le pare-feu entre le client et le serveur. Si vous ne pouvez pas effectuer l’une de ces opérations, vous devez basculer votre instance SQL Server vers un port statique et utiliser la procédure décrite dans Configurer un serveur pour écouter sur un port TCP spécifique.

    • Scénario 2 : Configuration de port statique. Soit SQL Server Navigateur n’est pas en cours d’exécution, soit UDP 1434 ne peut pas être ouvert sur le pare-feu. Dans ce cas, veillez à spécifier le port statique dans votre chaîne de connexion et que le pare-feu ne bloque pas le port. Pour plus d’informations, consultez Configurer un pare-feu Windows pour l’accès au moteur de base de données.

Étape 6 : Vérifier les protocoles activés sur SQL Server

Dans certaines installations de SQL Server, les connexions au moteur de base de données à partir d’un autre ordinateur ne sont pas activées, sauf si un administrateur les active manuellement. Vous pouvez utiliser l’une des options suivantes pour vérifier et activer les protocoles nécessaires pour autoriser les connexions à distance à SQL Server moteur de base de données.

Option 1 : Utilisation du fichier de sortie à partir de l’outil SQLCheck

  1. Recherchez la section « Détails de SQL Server instance » dans le fichier de sortie SQLCheck et recherchez la section d’informations de votre instance SQL Server.

  2. Dans la section, recherchez les valeurs répertoriées dans le tableau suivant pour déterminer si les protocoles SQL Server sont activés :

    Nom de la valeur Implication Plus d’informations
    Mémoire partagée activée Peut être vrai de false : affecte uniquement les connexions locales. Création d’une chaîne de connexion valide à l’aide du protocole de mémoire partagée
    Canaux nommés activés Si la valeur est false, les connexions locales et distantes utilisant des canaux nommés échouent Choix d’un protocole réseau
    TCP activé Si la valeur est false, les connexions locales et distantes utilisant TCP/IP échouent.
    Note La majorité des installations SQL Server utilisent TCP/IP comme protocole de communication entre le serveur et le client.
    Choix d’un protocole réseau
  3. Activez les protocoles requis à l’aide de Gestionnaire de configuration SQL Server ou SQL Server PowerShell. Pour plus d’informations, consultez Activer ou désactiver un protocole réseau de serveur.

    Notes

    Après l’activation d’un protocole, le moteur de base de données doit être arrêté et redémarré pour que la modification prenne effet.

Option 2 : Utiliser Gestionnaire de configuration SQL Server

Pour activer les connexions à partir d’un autre ordinateur à l’aide de la Gestionnaire de configuration SQL Server, procédez comme suit :

  1. Ouvrez le Gestionnaire de configuration SQL Server.

  2. Dans le volet gauche, développez SQL Server Configuration réseau, puis sélectionnez l’instance de SQL Server à laquelle vous souhaitez vous connecter. Le volet droit répertorie les protocoles de connexion disponibles. La mémoire partagée est normalement activée. Il ne peut être utilisé qu’à partir du même ordinateur, de sorte que la plupart des installations laissent la mémoire partagée activée. Pour vous connecter à SQL Server à partir d’un autre ordinateur, utilisez TCP/IP. Si TCP/IP n’est pas activé, cliquez avec le bouton droit sur TCP/IP, puis sélectionnez Activer.

  3. Si vous modifiez le paramètre activé pour n’importe quel protocole, redémarrez le moteur de base de données. Dans le volet gauche, sélectionnez SQL Server Services. Dans le volet droit, cliquez avec le bouton droit sur l’instance du moteur de base de données, puis sélectionnez Redémarrer.

Étape 7 : Tester la connectivité TCP/IP

La connexion à SQL Server à l’aide de TCP/IP nécessite que Windows établisse la connexion. Vous pouvez utiliser les étapes suivantes pour tester la connectivité TCP à l’aide de l’outil ping.

  1. Dans le menu Démarrer , sélectionnez Exécuter. Dans la fenêtre Exécuter , tapez cmd et sélectionnez OK.

  2. Dans la fenêtre d’invite de commandes, tapez ping et l’adresse IP de l’ordinateur qui exécute SQL Server. Par exemple :

    • IPv4 : ping 192.168.1.101
    • IPv6 : ping fe80::d51d:5ab5:6f09:8f48%11
  3. Si votre réseau est correctement configuré, ping retourne des Reply from <IP address> informations supplémentaires. En ping cas de Destination host unreachable retour ou Request timed out, TCP/IP n’est pas correctement configuré. Les erreurs à ce stade indiquent un problème avec l’ordinateur client, l’ordinateur serveur ou quelque chose sur le réseau, tel qu’un routeur. Pour résoudre les problèmes réseau, consultez Résolution avancée des problèmes TCP/IP.

  4. Si le ping test réussit à l’aide de l’adresse IP, testez si le nom de l’ordinateur peut être résolu en adresse TCP/IP. Sur l’ordinateur client, dans la fenêtre d’invite de commandes, tapez ping et le nom de l’ordinateur qui exécute SQL Server. Par exemple : ping newofficepc.

  5. Si le test ping sur l’adresse IP réussit, mais que le test ping sur le nom de l’ordinateur est retourné Destination host unreachable ou Request timed out, vous pouvez avoir d’anciennes informations de résolution de noms (obsolètes) mises en cache sur l’ordinateur client. Tapez ipconfig /flushdns pour effacer le cache DNS (Dynamic Name Resolution). Ensuite, effectuez à nouveau un test ping sur l’ordinateur par son nom. Lorsque le cache DNS est vide, l’ordinateur client vérifie les dernières informations sur l’adresse IP de l’ordinateur serveur.

  6. Si votre réseau est correctement configuré, ping retourne des Reply from <IP address> informations supplémentaires. Si vous pouvez effectuer un test ping sur l’ordinateur serveur par adresse IP, mais que vous recevez une erreur telle que Destination host unreachable ou Request timed out lorsque vous effectuez un test ping par nom d’ordinateur, la résolution de noms n’est pas correctement configurée. Pour plus d’informations, voir comment résoudre les problèmes TCP/IP de base. La résolution de noms réussie n’est pas nécessaire pour se connecter à SQL Server. Toutefois, si le nom de l’ordinateur ne peut pas être résolu en adresse IP, des connexions doivent être établies pour spécifier l’adresse IP. La résolution de noms peut être corrigée ultérieurement.

Notes

Vous pouvez également utiliser l’applet de commande Test-NetConnection ou Test-Connection pour tester la connectivité TCP en fonction de la version de PowerShell installée sur l’ordinateur. Pour plus d’informations sur l’applet de commande PowerShell, consultez Vue d’ensemble de l’applet de commande.

Étape 8 : Tester la connexion locale

Avant de résoudre un problème de connexion à partir d’un autre ordinateur, testez votre capacité à vous connecter à partir d’une application cliente installée localement sur l’ordinateur qui exécute SQL Server. La connexion locale évite les problèmes liés aux réseaux et aux pare-feu.

Cette procédure nécessite SQL Server Management Studio. Si Management Studio n’est pas installé, consultez Télécharger SQL Server Management Studio (SSMS).

Si vous ne pouvez pas installer Management Studio, vous pouvez tester la connexion à l’aide de l’utilitaire sqlcmd.exe . sqlcmd.exe est installé avec le moteur de base de données. Pour plus d’informations sur sqlcmd.exe, consultez l’utilitaire sqlcmd.

  1. Connectez-vous à l’ordinateur sur lequel SQL Server est installé à l’aide d’une connexion qui peut accéder à SQL Server. Pendant l’installation, SQL Server nécessite au moins une connexion à spécifier en tant qu’administrateur SQL Server. Si vous ne connaissez pas d’administrateur, consultez Se connecter à SQL Server lorsque les administrateurs système sont verrouillés.

  2. Dans la page Démarrer, tapez SQL Server Management Studio ou dans le menu Démarrer des versions antérieures de Windows, sélectionnez Tous les programmes, sélectionnez Microsoft SQL Server, puis sélectionnez SQL Server Management Studio.

  3. Dans le menu déroulant Se connecter , sélectionnez Moteur de base de données. Dans la zone Authentification , sélectionnez Authentification Windows. Dans la zone Nom du serveur , tapez l’un des types de connexion suivants :

    Connexion à Type Exemple
    Instance par défaut <computer name> ACCNT27
    Instance nommée <computer name\instance name> ACCNT27\PAYROLL

    Notes

    Lors de la connexion à SQL Server à partir d’une application cliente sur le même ordinateur, le protocole de mémoire partagée est utilisé. La mémoire partagée étant un type de canal nommé local, vous rencontrez parfois des erreurs liées aux canaux.

  4. Si vous recevez une erreur à ce stade, vous devez la résoudre avant de continuer. Votre connexion peut ne pas être autorisée à se connecter. Votre base de données par défaut peut être manquante.

    Notes

    Vous ne pouvez pas résoudre le problème sans suffisamment d’informations, car certains messages d’erreur sont transmis intentionnellement au client. Il s’agit d’une fonctionnalité de sécurité pour éviter de fournir à un attaquant des informations sur SQL Server. Pour afficher les détails de l’erreur, consultez le journal des erreurs SQL Server.

  5. Si vous recevez l’erreur 18456 Échec de connexion pour l’utilisateur, l’article De la documentation en ligne MSSQLSERVER_18456 contient des informations supplémentaires sur les codes d’erreur. Le blog d’Aaron Bertrand contient également une liste complète de codes d’erreur dans Troubleshooting Error 18456 (lien externe). Vous pouvez afficher le journal des erreurs à l’aide de SSMS (si vous pouvez vous connecter) dans la section Gestion du Explorateur d'objets. Sinon, vous pouvez afficher le journal des erreurs avec le programme du Bloc-notes Windows. L’emplacement par défaut varie en fonction de votre version et peut être modifié pendant l’installation. L’emplacement par défaut pour SQL Server 2019 (15.x) est C:\Program Files\Microsoft SQL Server\MSSQL15. MSSQLSERVER\MSSQL\Log\ERRORLOG.

  6. Si vous pouvez vous connecter à l’aide de la mémoire partagée, testez la connexion à l’aide de TCP. Vous pouvez forcer une connexion TCP en spécifiant tcp: avant le nom. Voici les exemples suivants :

    Connexion à : Type : Exemple :
    Instance par défaut tcp:<computer name> tcp:ACCNT27
    Instance nommée tcp:<computer name/instance name> tcp:ACCNT27\PAYROLL
  7. Si vous pouvez vous connecter à l’aide de la mémoire partagée, mais pas de TCP, vous devez résoudre le problème TCP. Le problème le plus probable est que TCP n’est pas activé. Pour activer TCP, consultez l’étape 6 : Vérifiez les protocoles activés sur SQL Server.

  8. Si votre objectif est de vous connecter à l’aide d’un compte autre qu’un compte d’administrateur, vous pouvez commencer par vous connecter en tant qu’administrateur. Ensuite, essayez de vous reconnecter avec la connexion d’authentification Windows ou la connexion d’authentification SQL Server utilisée par l’application cliente.

Étape 9 : Tester la connexion à distance

Une fois que vous pouvez vous connecter à l’aide de TCP sur le même ordinateur, il est temps d’essayer de vous connecter à partir de l’ordinateur client. Vous pouvez utiliser n’importe quelle application cliente, mais pour éviter toute complexité, installez les outils de gestion SQL Server sur le client. Après l’installation, essayez d’utiliser SQL Server Management Studio.

  1. Utilisez SQL Server Management Studio sur l’ordinateur client et essayez de vous connecter à l’aide de l’adresse IP et du numéro de port TCP au format numéro de port de virgule d’adresse IP. Par exemple : 192.168.1.101,1433. Si cette connexion échoue, vous rencontrez probablement l’un des problèmes suivants :

  2. Une fois que vous pouvez vous connecter à l’aide de l’adresse IP et du numéro de port, passez en revue les scénarios suivants :

    • Si vous vous connectez à une instance par défaut qui écoute sur un port autre que 1433, vous devez utiliser le numéro de port dans la chaîne de connexion ou créer un alias sur l’ordinateur client pour vous connecter à l’instance par défaut. Le service SQL Server Browser ne peut pas énumérer les ports de l’instance par défaut.

    • Si vous vous connectez à une instance nommée, essayez de vous connecter à l’instance au format du nom de l’instance de barre oblique inverse de l’adresse IP. (Par exemple, 192.168.1.101\<instance name>.) Si cette action ne fonctionne pas, cela signifie que le numéro de port n’est pas retourné au client. Le problème est lié au service SQL Server Browser, qui fournit au client le numéro de port d’une instance nommée. Voici les solutions :

      • Démarrez le service SQL Server Browser. Consultez les instructions de démarrage du navigateur dans Gestionnaire de configuration SQL Server.
      • Le service SQL Server Browser est bloqué par le pare-feu. Ouvrez le port UDP 1434 dans le pare-feu. Retour à la section Étape 5 : Vérifier la configuration du pare-feu. Assurez-vous que vous ouvrez un port UDP, et non un port TCP.
      • Les informations du port UDP 1434 sont bloquées par un routeur. La communication UDP (protocole de datagramme utilisateur) n’est pas conçue pour passer les routeurs et empêche le réseau de se remplir de trafic de faible priorité. Vous pouvez configurer votre routeur pour transférer le trafic UDP, ou vous pouvez fournir le numéro de port chaque fois que vous vous connectez.
      • Si l’ordinateur client utilise Windows 7, Windows Server 2008 ou un système d’exploitation plus récent, le système d’exploitation client peut supprimer le trafic UDP, car la réponse du serveur est retournée à partir d’une autre adresse IP interrogée. Cette action est une fonctionnalité de sécurité qui bloque le « mappage de source libre ». Pour plus d’informations, consultez la section Adresses IP de plusieurs serveurs de l’article Dépannage de la documentation en ligne : Expiration du délai d’expiration. (Cet article provient de SQL Server 2008 R2, mais les principaux s’appliquent toujours. Vous pouvez configurer le client pour utiliser l’adresse IP correcte ou fournir le numéro de port chaque fois que vous vous connectez.)
  3. Une fois que vous pouvez vous connecter à l’aide de l’adresse IP (ou de l’adresse IP et du nom d’instance d’une instance nommée), essayez de vous connecter à l’aide du nom de l’ordinateur (ou du nom de l’ordinateur et de l’instance pour une instance nommée). Placez-le tcp: devant le nom de l’ordinateur pour forcer une connexion TCP/IP. Par exemple, pour l’instance par défaut sur un ordinateur nommé ACCNT27, utilisez tcp:ACCNT27. Pour une instance nommée appelée PAYROLL, sur cet ordinateur, utilisez tcp:ACCNT27\PAYROLL. Si vous pouvez vous connecter à l’aide de l’adresse IP, mais pas en utilisant le nom de l’ordinateur, vous rencontrez un problème de résolution de noms. Retour à la section Étape 7 : Tester la connectivité TCP/IP.

  4. Une fois que vous pouvez vous connecter à l’aide du nom d’ordinateur forçant TCP, essayez de vous connecter à l’aide du nom de l’ordinateur sans forcer TCP. Par exemple, pour une instance par défaut, utilisez simplement un nom d’ordinateur tel que CCNT27. Pour une instance nommée, utilisez le nom de l’ordinateur et le nom de l’instance comme ACCNT27\PAYROLL. Si vous pouvez vous connecter tout en forçant TCP, mais pas sans forcer TCP, le client utilise probablement un autre protocole tel que des canaux nommés. Pour résoudre ce problème, procédez comme suit :

    1. Sur l’ordinateur client, utilisez Gestionnaire de configuration SQL Server. Dans le volet gauche, développez SQL Native Client <version> Configuration, puis sélectionnez Protocoles clients.
    2. Dans le volet droit, assurez-vous que TCP/IP est activé. Si TCP/IP est désactivé, cliquez avec le bouton droit sur TCP/IP , puis sélectionnez Activer.
    3. Assurez-vous que l’ordre de protocole pour TCP/IP est inférieur à celui des canaux nommés (ou VIA sur les versions antérieures). En règle générale, vous devez laisser la mémoire partagée dans l’ordre 1 et TCP/IP dans l’ordre 2. La mémoire partagée est utilisée uniquement lorsque le client et SQL Server s’exécutent sur le même ordinateur. Tous les protocoles activés sont essayés dans l’ordre jusqu’à ce que l’un d’eux réussisse, mais la mémoire partagée est ignorée lorsque la connexion n’est pas sur le même ordinateur.

Voir aussi