SQL Server clients peuvent changer de protocole lorsque les ordinateurs clients tentent de se connecter à un instance de SQL Server

Cet article présente SQL Server clients peuvent changer de protocole lorsque les ordinateurs clients tentent de se connecter à un instance de SQL Server.

Version du produit d’origine : SQL Server
Numéro de la base de connaissances d’origine : 328383

Résumé

Les ordinateurs clients qui disposent de Microsoft Data Access Components (MDAC) version 2.6 ou ultérieure peuvent essayer plusieurs protocoles ou mécanismes de communication interprocessus (IPC) pour établir des connexions à SQL Server.

Plus d’informations

Une amélioration a été apportée à la bibliothèque réseau côté client, Dbnetlib.dll pour MDAC version 2.6 et ultérieure. Avec MDAC version 2.6 et versions ultérieures, si plusieurs protocoles sont disponibles et qu’une tentative de connexion avec le premier protocole échoue, l’application cliente tente immédiatement d’utiliser l’un des autres protocoles.

Par défaut, les clients ont des canaux TCP et nommés comme protocoles disponibles. Vous pouvez manipuler l’ordre du protocole à l’aide de l’utilitaire client SQL Server. L’application cliente utilise les protocoles dans l’ordre spécifié sur l’ordinateur client. L’ordre du protocole est stocké à l’emplacement de clé de Registre suivant sous la valeur ProtocolOrder :

HKLM\Software\Microsoft\MSSQLServer\Client\SuperSocketNetLib

Si vous utilisez SQL Server 2005, l’ordre du protocole est stocké dans l’entrée de Registre ProtocolOrder sous la sous-clé de Registre suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI<version>

Par exemple, si un ordinateur client a des canaux TCP et nommés disponibles, et que l’ordre est :

  • TCP
  • Canaux nommés

Lorsque l’ordinateur client tente d’établir une connexion TCP au serveur et que la tentative de connexion retourne un code de retour différent de zéro, le client tente en toute transparence une connexion à l’aide du protocole suivant dans la liste, qui est Canaux nommés. Dans ce scénario, le client ne peut pas établir de connexion TCP ; Toutefois, le client établit correctement une connexion de canaux nommés.

Remarque

Le client ne reçoit pas d’erreur indiquant que le premier protocole a échoué.

Si l’application cliente utilise le deuxième protocole et qu’elle retourne également une erreur, une erreur est retournée au client.

Si vous créez un alias à l’aide de l’une des méthodes suivantes, l’application cliente utilise les informations d’alias pour établir une connexion au serveur et n’utilise pas de protocoles supplémentaires.

  • À l’aide de l’utilitaire réseau client SQL Server
  • En utilisant Gestionnaire de configuration SQL Server
  • Lorsque vous créez un nom de source de données ODBC (DSN)

Si vous souhaitez contrôler le protocole utilisé par une application cliente pour chaque tentative de connexion et ne pas autoriser le client à essayer plusieurs protocoles, vous pouvez effectuer l’une des opérations suivantes :

  • Utilisez l’utilitaire sql Client Network ou Gestionnaire de configuration SQL Server pour créer un alias en spécifiant le protocole de votre choix.

  • Spécifiez le protocole dans votre chaîne de connexion. Par exemple :

    DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBMSSOCN;Address=IP_Address,1433;UID=YourUID;PWD=YourPassword;
    

    Dans cet exemple, vous spécifiez le protocole réseau comme DBMSSOCN, ce qui signifie que vous souhaitez utiliser le protocole TCP/IP. Si vous spécifiez le protocole à l’intérieur de votre chaîne de connexion, Dbnetlib utilise uniquement le protocole spécifié et n’essaie aucun autre protocole. De même, pour activer uniquement le protocole canal nommé, utilisez un chaîne de connexion semblable à ceci :

    DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBNMPNTW;Address=\\.\pipe\sql\query;UID=YourUID;PWD=YourPassword;
    
  • Utilisez l’utilitaire Réseau client pour supprimer d’autres protocoles.

RÉFÉRENCES

Résolution des erreurs de connectivité à SQL Server