Partager via

Une erreur de réseau ou d’instance spécifique s’est produite lors de l’établissement d’une connexion à SQL Server

  • Article

S'applique à : SQL Server

Lors de la connexion à une instance SQL Server, 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 :

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 propre à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou inaccessible. 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é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 de localisation du serveur/de l’instance spécifié Une erreur liée au réseau ou propre à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou inaccessible. Vérifiez que le nom de l’instance est correct et que SQL Server est configuré pour autoriser les connexions à distance.
fournisseur : Interfaces réseau SQL, erreur : 26 - Erreur de localisation du serveur/de l’instance spécifié

Expiration du délai d’expiration de la connexion Erreur de liaison de données du client natif du serveur SQL
[Microsoft SQL Server Native Client 10.0] : expiration du délai d’expiration de la connexion
[Microsoft SQL Server Native Client 10.0] : une erreur propre au réseau ou à 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 si le nom de l'instance est correct et si SQL Server est configuré pour autoriser les connexions distantes. 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 de localisation du serveur/de l’instance spécifiée [xFFFFFFFF].

Échec de la tentative de connexion parce que la partie connectée n'a pas répondu correctement après un certain laps de temps ou la connexion établie a échoué parce que l'hôte connecté n'a pas pu répondre Une erreur liée au réseau ou propre à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou inaccessible. 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
Échec de la tentative de connexion parce que la partie connectée n’a pas répondu correctement après un certain laps de temps ou la connexion établie a échoué parce que l’hôte connecté n’a pas pu répondre.
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 propre à une instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou inaccessible. 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és, 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é activement 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 si le nom de l'instance est correct et si SQL Server est configuré pour autoriser les connexions distantes. 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.

Note

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

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

Le message complet est :

Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus de connexion. (fournisseur : Fournisseur de mémoire partagée, erreur : 0 - Il n’y a pas de processus à 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 suivre les é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 :

Note

Le Gestionnaire de configuration est automatiquement installé sur l’ordinateur en même temps que l’installation de SQL Server. Les instructions de démarrage du Gestionnaire de configuration diffèrent légèrement selon les versions de SQL Server et de Windows. Pour plus d’informations spécifiques à la version, consultez la section Gestionnaire de configuration SQL Server.

  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 <le 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 <le 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.

    Note

    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 l’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.

    Note

    • 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. Recherchez dans le fichier de sortie SQLCHECK « INFORMATIONS SQL Server ».
  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

Note

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

Option 1 : Utiliser le fichier de sortie SQLCHECK

  1. Recherchez dans le fichier de sortie SQLCHECK « INFORMATIONS SQL Server ».
  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.

Note

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

É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.

Note

Si vous utilisez l’outil SQLCHECK, passez en revue les valeurs NetBios Name/FQDN dans la section Informations sur l’ordinateur du fichier de sortie.

É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.

Note

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

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 qu’il prodsql s’agit d’un alias pour un serveur 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. 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 à 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.

Note

Ces concepts sont applicables même si vous utilisez des pare-feu tiers dans votre réseau. Toutefois, vous devrez peut-être travailler avec votre administrateur réseau ou consulter la documentation produit du pare-feu pour en savoir plus 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 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.
    • 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.
      • 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 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. Recherchez dans le fichier de sortie SQLCHECK la section « Détails de l’instance SQL Server » et recherchez la section informations de votre instance SQL Server.

  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 Activer ou désactiver un protocole réseau de serveur.

    Note

    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.

Note

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 la section Présentation 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 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 boîte 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

    Note

    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.

    Note

    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 à : Tapez : 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 avez 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 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. Voici les solutions :
      • Démarrez 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 de source libre ». Pour plus d’informations, consultez la section Adresses IP multiples du guide de résolution des problèmes liés à 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 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 Configuration de la version> de SQL Native Client<, 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 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, vérifiez si un utilisateur dispose des autorisations nécessaires pour se connecter à Windows. Pour plus d’informations, consultez Résolution des problèmes liés aux connexions de canaux nommés.

Voir aussi