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

S’applique à : SQL Server

Lorsque vous vous connectez à un SQL Server instance, vous pouvez rencontrer un ou plusieurs des messages d’erreur suivants. Cet article fournit quelques étapes pour vous aider à résoudre ces erreurs, qui sont classées de la plus simple à la plus complexe.

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. Consultez les détails suivants pour voir si vous avez déjà rencontré l’un de ces messages d’erreur :

« Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. »

              

                             

fournisseur : fournisseur de canaux nommés, erreur : 40 – Impossible d’ouvrir une connexion à SQL Server (Microsoft SQL Server, erreur : 53)

Une erreur liée au réseau ou spécifique à l’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é de manière à autoriser les connexions à distance.
fournisseur : fournisseur de canaux nommés, erreur : 40 – Impossible d’ouvrir une connexion à SQL Server (Microsoft SQL Server, erreur : 53)
fournisseur : fournisseur TCP, erreur : 0 – Hôte inconnu. (Microsoft SQL Server, Erreur : 11001)

              

              

                             

fournisseur : interfaces réseau SQL, erreur : 26 – Erreur lors de la localisation du serveur/de l’instance spécifiés

Une erreur liée au réseau ou spécifique à l’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é de manière à autoriser les connexions à distance.
fournisseur : interfaces réseau SQL, erreur : 26 – Erreur lors de la localisation du serveur/de l’instance spécifiés

              

              

                             

Délai de connexion expiré

Erreur de liaison de données du client natif du serveur SQL
[Microsoft SQL Server Native Client 10.0] : Expiration du délai de connexion.
[Microsoft SQL Server Native Client 10.0] : Une erreur liée au réseau ou spécifique à l’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 d’instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. Pour plus d’informations, reportez-vous à la documentation en ligne de SQL Server.
[Microsoft SQL Server Native Client 10.0] : Interfaces réseau SQL Server : Erreur lors de la localisation du serveur/instance spécifié [xFFFFFFFF].

              

              

                             

Une tentative de connexion a échoué, car le participant connecté n’a pas répondu convenablement au-delà d’une certaine durée ou bien 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 à l’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é de manière à autoriser les connexions à distance.
fournisseur : fournisseur TCP, erreur : 0
Une tentative de connexion a échoué, car le participant connecté n’a pas répondu convenablement au-delà d’une certaine durée ou bien 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és, erreur : 40 - Impossible d’ouvrir une connexion à SQL Server

Une erreur liée au réseau ou spécifique à l’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é de manière à autoriser les connexions à distance.
fournisseur : fournisseur de canaux nommés, erreur : 40 – Impossible d’ouvrir une connexion à SQL Server
Microsoft SQL Server, Erreur : 53
Le chemin réseau n’a pas été trouvé.

              

              

                             

[Microsoft] [SQL Server Native Client 11.0] Fournisseur TCP : aucune connexion n’a pu être établie, car l’ordinateur cible la refuse expressément.

Erreur de liaison de données du client natif du serveur SQL
[Microsoft] [SQL Server Native Client 11.0]Fournisseur TCP : aucune connexion n’a pu être établie, car l’ordinateur cible la refuse expressément.
[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 à l’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 d’instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. Pour plus d’informations, reportez-vous à la documentation en ligne de SQL Server.

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

Ce message d’erreur signifie généralement que le client ne trouve pas l’instance de SQL Server. Ce problème peut se produire lorsqu’au moins une des conditions suivantes est remplie :

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

Erreur Windows 233 : Aucun processus n’est à l’autre extrémité du canal

Le message complet est le suivant :

Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus d’ouverture de session. (fournisseur : Fournisseur de mémoire partagée, erreur : 0 - Aucun processus n’est à l’autre extrémité du canal.) (Microsoft SQL Server, Erreur : 233)

Ce message signifie que SQL Server n’écoute pas sur le protocole mémoire partagée ou canaux nommés.

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 suivantes avant de passer aux étapes réelles pour résoudre l’erreur.

Option 1 : utiliser l’outil SQLCheck pour collecter les informations requises

Si vous pouvez vous connecter localement à l’ordinateur SQL Server et disposer d’un accès administrateur, utilisez SQLCHECK. Cet outil fournit la plupart des informations requises pour résoudre les problèmes d’un fichier. Consultez la page d’accueil de l’outil pour en savoir plus sur son utilisation et les informations qu’il collecte. Vous pouvez également consulter les prérequis recommandés et la liste de vérification.

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

Obtenir le nom d’instance à partir du Gestionnaire de configuration

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

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

2. Démarrez le Gestionnaire de configuration SQL Server.

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

4. Dans le volet droit, vérifiez le nom de l’instance du moteur de la 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 <nom de l’ordinateur>.
   •               SQL SERVER (<nom de l’instance>) indique une instance nommée de SQL Server. Le nom de l’instance nommée est <nom de l’ordinateur>\<nom de l’instance>.

Obtenir l’adresse IP du serveur

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

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

2. Dans la fenêtre Invite de commandes, tapez ipconfig/all, puis appuyez sur Entrée : Notez les adresses IPv4 et IPv6.

   Remarque

   SQL Server peut se connecter à l’aide du protocole IP version 4 ou du protocole IP version 6. Votre réseau peut en autoriser un ou les deux.

Obtenir le port TCP de l’instance

Dans la plupart des cas, vous pouvez vous connecter au moteur de la base de données sur un autre ordinateur à l’aide du protocole TCP. Pour trouver 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 Journaux SQL Server, puis double-cliquez sur le journal actuel.

2. Dans la boîte de dialogue Visionneuse du fichier journal, sélectionnez Filtre dans la barre d’outils. Dans la zone Message contenant du texte, tapez Le serveur est en écoute, sélectionnez Appliquer filtre, puis cliquez sur OK.

3. Un message tel que « Le serveur écoute sur [ 'any' <ipv4> 1433] » doit être répertorié.

   Ce message indique que l’instance de SQL Server est en écoute sur toutes les adresses IP de cet ordinateur (pour l’adresse IP version 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 un autre port numéros.) Notez le numéro de port utilisé par l’instance SQL Server à laquelle vous essayez de vous connecter.

   Remarque

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

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

Option 1 : Utiliser le fichier de sortie SQLCHECK

1. Recherche le fichier de sortie SQLCHECK pour « SQL Server Information ».
2. Dans la section intitulée « Services d’intérêt », recherchez votre instance de 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é. Si la valeur est définie sur Vrai, les services ont été démarrés. Autrement, 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, du Gestionnaire de configuration SQL Server, de PowerShell ou de l’applet Services.

Option 2 : utiliser le Gestionnaire de configuration SQL Server

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

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

Si l’instance est arrêtée, cliquez avec le bouton droit de la souris sur l’instance et sélectionnez Démarrer. L’instance de serveur démarre ensuite et l’indicateur laisse apparaître une flèche verte.

Option 3 : utiliser les 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 -like "sql server*"}

Vous pouvez utiliser la commande suivante pour parcourir le fichier du journal des erreurs à la recherche de la chaîne spécifique « SQL Server est désormais prêt pour les connexions clients. Ceci est un message d’information ; aucune action n’est requise de la part de l’utilisateur. » :

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 SQL Server Browser est en cours d’exécution

Option 1 : Utiliser le fichier de sortie SQLCHECK

1. Recherche le fichier de sortie SQLCHECK pour « SQL Server Information ».
2. Dans la section intitulée « Services d’intérêt », recherchez SQLBrowser dans la colonne Nom puis vérifiez son état à l’aide de la colonne Démarré. Si la valeur est définie sur Vrai, le service a été démarré. Autrement, le service n’est pas en cours d’exécution et vous devez le faire démarrer. Pour plus d’informations, consultez la section Démarrer, arrêter, suspendre, reprendre, redémarrer les services SQL Server.

Option 2 : utiliser le 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 le 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 la section Service SQL Server Browser.

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

É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é lors des étapes précédentes.

• Pour obtenir des exemples sur les chaînes de connexion, consultez la section Chaînes de connexion SQL Server.
• Pour des exemples plus détaillés, consultez la section Preuve de concept se connectant à SQL à l’aide de ADO.NET sous Page d’accueil pour la programmation du client SQL.

Étape 4 : vérifier les alias sur les ordinateurs du client

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 du Gestionnaire de configuration SQL Server ou de l’utilitaire réseau du client. Un alias incorrect peut entraîner la connexion de vos applications au mauvais serveur, ce qui entraînerait un échec. Utilisez les méthodes suivantes pour vérifier les alias incorrects. Vous pouvez également utiliser un outil (tel que SQLCHECK) sur l’ordinateur du client pour rechercher des alias et divers autres paramètres liés à la connectivité d’un ordinateur client.

Option 1 : Utiliser le fichier de sortie 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 sur le pilote du fichier)
2. Examinez les données entrées dans le tableau. S’il n’y en a aucune, c’est qu’il n’y a pas d’alias sur l’ordinateur. S’il existe une entrée, examinez 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      

La sortie indique que prodsql est un alias pour un SQL Server appelé prod_sqlserver qui s’exécute sur le port 1430.

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

1. Dans le Gestionnaire de configuration SQL Server, développez Configuration de SQL Server Native Client, puis sélectionnez Alias.

2. Vérifiez si des alias sont définis pour le serveur auquel vous essayez de vous connecter.

   Si un ou plusieurs alias existent, procédez comme suit :

   1. Ouvrez le volet Propriétés de l’alias.
   2. Renommez la valeur figurant dans le champ Nom de l’alias (par exemple, si votre nom de serveur est MonSQL, renommez-le MonSQL_test) et réessayez de vous connecter. Si la connexion fonctionne, c’est que votre alias est incorrect et qu’il vient probablement d’une ancienne configuration qui n’est plus nécessaire. Si la connexion ne fonctionne pas, rétablissez le nom original de l’alias et passez à l’étape suivante.
   3. Vérifiez les paramètres de connexion de l’alias et assurez-vous qu’ils sont corrects. Voici quelques-uns des scénarios les plus courants pouvant poser des problèmes de connectivité :
      • Adresse IP incorrecte pour le champ Serveur. Assurez-vous que l’adresse IP correspond à celle présente dans le fichier du journal des erreurs SQL Server.
      • Nom de serveur incorrect dans le champ Serveur. Par exemple, votre alias de serveur pointe vers le bon nom de serveur. Toutefois, la connexion continuera à échouer si la valeur du paramètre Nom de serveur est incorrecte.
      • Format de nom de canal incorrect (en supposant que vous utilisez un alias de canaux nommés).
        • 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 l’utilitaire réseau du client SQL Server

1. Ouvrez l’utilitaire réseau du client SQL Server en tapant cliconfg.exe dans votre commande Exécuter.
2. Suivez l’étape 2 de l’option 2 : vérifier les alias dans le 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.

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 lʼétat du service, procédez comme suit :

1. Déterminez sur quel port s’exécute votre instance SQL. Pour cela, consultez la section Obtenir le port TCP de l’instance.
2. • Si votre SQL Server est configuré pour être en écoute sur le port 1433, assurez-vous que les pare-feu du réseau entre le client et le serveur autorisent le trafic sur ce port. Consultez la section Configurer un pare-feu Windows pour accéder au moteur de base de données et collaborez avec votre administrateur réseau pour implémenter les solutions nécessaires.
   • Si votre instance de SQL Server 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 cela fonctionne. Par exemple, le nom de votre instance de SQL est MySQLDefaultinstance et elle s’exécute sur le port 2000. Spécifiez le nom de serveur sous la forme MySQLServer, 2000, et voyez si cela fonctionne.
     • Si cela ne fonctionne pas, cela indique que le pare-feu bloque le port. Dasn ce cas, suivez les instructions de la section Configurer un pare-feu Windows pour accéder au moteur de base de données ou collaborer avec votre administrateur réseau pour ajouter le port à la liste d’exclusions 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 de SQL est une instance nommée, elle peut être configurée pour utiliser des ports dynamiques ou un port statique. Dans un cas comme dans l’autre, les bibliothèques réseau sous-jacentes interrogent le service SQL Server Browser s’exécutant sur votre ordinateur SQL Server via le port UDP 1434 pour énumérer le numéro de port de l’instance nommée. Si un pare-feu situé entre le client et le serveur bloque ce port UDP, la bibliothèque cliente ne peut pas déterminer le port (exigence de connexion) et la connexion échoue. Pour vérifier la connexion, utilisez 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 sur quel port s’exécute votre instance SQL. Pour cela, consultez la section 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 le nom de votre instance SQL est MySQL\Namedinstance et qu’elle s’exécute sur le port 3000, spécifiez le nom du serveur sous la forme 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.
     • Dans le cas contraire, cela indique que vous rencontrez 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 l’outil Portqry.
       • L’instance est masquée dans le 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 cet outil, consultez l’article 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 adaptée à votre scénario ci-dessous. Si vous n’êtes pas sûr, consultez l’article Comment vérifier si SQL Server écoute sur un port dynamique ou un port statique.

  • Scénario 1 : Ports dynamiques. Dans ce cas, assurez-vous 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 Browser n’est pas en cours d’exécution, soit le port 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 à ce que le pare-feu ne bloque pas le port. Pour plus d’informations, consultez l’article Configurer un pare-feu Windows pour accéder 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 au moteur de base de données SQL Server.

Option 1 : Utiliser le fichier de sortie SQLCHECK

1. Recherche le fichier de sortie SQLCHECK pour la section « Détails pour SQL Server instance » et recherchez la section d’informations pour votre SQL Server instance.

2. Dans cette 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	La valeur peut être true ou false. Cela 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 à distance qui utilisent des canaux nommés échouent.	Choix d’un protocole réseau
   TCP activé	Si la valeur est false, les connexions locales et à distance qui utilisent TCP/IP échouent. Remarque 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 du Gestionnaire de configuration SQL Server ou de SQL Server PowerShell. Pour plus d’informations, consultez la section Activer ou désactiver un protocole réseau de serveur.

   Remarque

   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 le Gestionnaire de configuration SQL Server

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

1. Ouvrez le Gestionnaire de configuration SQL Server.
2. Dans le volet gauche, développez Configuration du réseau SQL Server, 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. Elle ne peut être utilisée qu’à partir du même ordinateur, c’est pourquoi la plupart des installations laissent la mémoire partagée activée. Pour vous connecter à SQL Server à partir d’un autre ordinateur, utilisez le protocole TCP/IP. Si le protocole 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 d’activation d’un protocole, vous devez redémarrer le moteur de base de données. Dans le volet gauche, sélectionnez Services SQL Server. Dans le volet droit, cliquez avec le bouton droit sur l’instance du moteur de base de données, puis cliquez sur Redémarrer.

Étape 7 : tester la connectivité TCP/IP

Pour se connecter à SQL Server à l’aide du protocole TCP/IP, Windows doit établir la connexion. Les étapes suivantes vous permettent de 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, saisissez cmd, puis cliquez sur OK.
2. Dans la fenêtre Invite de commandes, saisissez ping ainsi que 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 renvoie Reply from <IP address> ainsi que des informations supplémentaires. Si ping renvoie Destination host unreachable ou Request timed out, cela signifie que le protocole TCP/IP n’est pas correctement configuré. Les erreurs à ce stade indiquent un problème avec l’ordinateur client, l’ordinateur SQL Server ou un élément du réseau, tel qu’un routeur. Pour résoudre les problèmes liés au réseau, consultez l’article Résolution avancée des problèmes liés au protocole TCP/IP.
4. Si le test ping réussit en utilisant l’adresse IP, vérifiez si le nom de l’ordinateur peut être résolu en adresse TCP/IP. Sur l’ordinateur client, dans la fenêtre Invite de commandes, saisissez ping ainsi que 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 renvoie Destination host unreachable ou Request timed out, il se peut que les informations de résolution de nom soient anciennes (périmées) et mises en cache sur l’ordinateur client. Saisissez ipconfig /flushdns pour vider le cache DNS (Dynamic Name Resolution). Effectuez ensuite un nouveau test Ping sur le nom de l’ordinateur. Lorsque le cache DNS est vide, l’ordinateur client vérifie les dernières informations concernant l’adresse IP de l’ordinateur serveur.
6. Si votre réseau est correctement configuré, ping renvoie Reply from <IP address> ainsi que des informations supplémentaires. Si vous pouvez effectuer un test Ping sur l’ordinateur serveur par l’adresse IP, mais qu’un test Ping par le nom de l’ordinateur échoue et renvoie une erreur telle que Destination host unreachable ou Request timed out, alors la résolution de nom n’est pas correctement configurée. Pour plus d’informations, consultez l’article Résolution des problèmes TCP/IP de base. Une 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, il faut établir des connexions pour spécifier l’adresse IP. La résolution de noms peut être corrigée ultérieurement.

É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 client installée localement sur l’ordinateur qui exécute SQL Server. La connexion locale permet d’éviter les problèmes liés aux réseaux et aux pare-feu.

Pour réaliser cette procédure, vous avez besoin de SQL Server Management Studio. Si Management Studio n’est pas installé, consultez l’article 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 dotée de privilèges administrateur SQL Server. Si vous ne connaissez pas d’administrateur, consultez l’article Se connecter à SQL Server lorsque les administrateurs système sont verrouillés.

2. Sur la page Démarrer, saisissez SQL Server Management Studio. Pour les versions antérieures de Windows, dans le menu Démarrer, sélectionnez Tous les programmes, puis Microsoft SQL Server et 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, saisissez 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

   Remarque

   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.

   Remarque

   Vous ne pouvez pas résoudre le problème sans un nombre suffisant d’informations. En effet, certains messages d’erreur sont transmis intentionnellement au client. Il s’agit d’une fonctionnalité de sécurité destinée à é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 la connexion pour l’utilisateur », l’article de la documentation en ligne MSSQLSERVER_18456 contient des informations supplémentaires sur les codes d’erreur. La page Troubleshooting Error 18456 (lien externe), disponible sur le blog d’Aaron Bertrand, contient également une liste complète de codes d’erreur. Vous pouvez afficher le journal des erreurs à l’aide de SSMS (si vous pouvez vous connecter) dans la section Gestion de l’Explorateur d’objets. Vous pouvez également afficher le journal des erreurs avec le 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 du protocole TCP. Vous pouvez forcer une connexion TCP en spécifiant tcp: avant le nom. Voici quelques exemples :

   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 du protocole TCP, vous devez résoudre le problème lié au protocole TCP. Le problème le plus probable est que le protocole TCP n’est pas activé. Pour activer le protocole TCP, consultez la section Étape 6 : vérifier 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. Essayez ensuite de vous reconnecter avec les identifiants d’authentification Windows ou avec les identifiants de connexion SQL Server utilisés par l’application client.

Étape 9 : tester la connexion à distance

Une fois qu’il est possible de vous connecter au même ordinateur à l’aide du protocole TCP, il est temps d’essayer de vous connecter à partir de l’ordinateur client. Vous pouvez utiliser n’importe quelle application client, mais pour éviter toute complexité, installez les outils de gestion SQL Server sur l’ordinateur 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 en suivant le format Adresse IP virgule Numéro de port. Par exemple : 192.168.1.101,1433. Si cette connexion échoue, vous rencontrez probablement l’un des problèmes suivants :
   • ping de l’adresse IP ne fonctionne pas. Cela indique un problème de configuration général du protocole TCP. Retournez à la section Étape 7 : tester la connectivité du protocole TCP/IP.
   • SQL Server n’écoute pas le protocole TCP. Retournez à la section Étape 6 : vérifier les protocoles activés sur SQL Server.
   • SQL Server est en écoute sur un port autre que celui que vous avez spécifié. Retournez à la section Obtenir le port TCP.
   • Le port TCP SQL Server est bloqué par le pare-feu. Retournez à la section Étape 5 : vérifier la configuration du pare-feu.
2. Une fois qu’il est possible de vous connecter à l’aide de l’adresse IP et du numéro de port, examinez les scénarios suivants :
   • Si vous vous connectez à une instance par défaut en é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 en suivant le format Adresse IP barre oblique inverse Nom de l’instance. (Par exemple, 192.168.1.101\<instance name>.) Si cela ne fonctionne pas, cela signifie que le numéro de port n’a pas été renvoyé 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. Essayez les solutions suivantes :
     • Activez le service SQL Server Browser. Consultez les instructions de démarrage du navigateur dans le Gestionnaire de configuration SQL Server.
     • Le service SQL Server Browser est bloqué par le pare-feu. Ouvrez le port UDP 1434 du pare-feu. Retournez à 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. Les communications utilisant le protocole UDP (User Datagram Protocol) ne sont pas conçues pour passer par les routeurs et empêchent le réseau de se saturer de trafic de faible priorité. Vous pouvez configurer votre routeur pour transférer le trafic UDP ou 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 interrompre 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é bloquant le « mappage source lâche ». Pour plus d’informations, consultez la section Adresses IP de serveurs multiples de l’article Dépannage : expiration du délai d’attente dans la documentation en ligne. (Cet article provient de SQL Server 2008 R2, mais les principaux s’appliquent toujours. Vous pouvez configurer le client pour qu’il utilise 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 pour 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 tcp: devant le nom de l’ordinateur pour forcer une connexion à l’aide du protocole 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, alors votre problème se situe au niveau de la résolution de nom. Retournez à la section Étape 7 : tester la connectivité du protocole TCP/IP.
4. Une fois qu’il est possible de vous connecter à l’aide du nom d’ordinateur qui est en train de forcer le protocole TCP, essayez de vous connecter à l’aide du nom d’ordinateur, mais sans forcer le protocole 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, par exemple des canaux nommés. Pour résoudre ce problème, procédez comme suit :
   1. Sur l’ordinateur client, utilisez le Gestionnaire de configuration SQL Server. Dans le volet gauche, développez la section Configuration <version> de SQL Native Client, puis sélectionnez Protocoles du client.
   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 définie en tant qu’ordre 1 et TCP/IP en tant qu’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.

Étape 10 : Vérifier les autorisations utilisateur

Si vous utilisez des canaux nommés pour vous connecter, case activée si un utilisateur dispose des autorisations nécessaires pour se connecter à Windows. Pour plus d’informations, consultez Résolution des problèmes de connexions de canaux nommés.

Voir aussi

• Protocoles réseau et bibliothèques réseau
• Configuration du réseau client
• Configurer les protocoles clients
• Résoudre les problèmes de connectivité dans SQL Server
• Problème de réseau constant 0200
• Se connecter à un écouteur de groupe de disponibilité Always On
• Instances de cluster de basculement Always On (SQL Server)
• Résolution des problèmes de connectivité et autres erreurs avec Azure SQL Database et Azure SQL Managed Instance