SQL Server Clients können Protokolle ändern, wenn die Clientcomputer versuchen, eine Verbindung mit einer instance SQL Server

In diesem Artikel wird erläutert, SQL Server Clients Protokolle ändern können, wenn die Clientcomputer versuchen, eine Verbindung mit einem instance SQL Server herzustellen.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 328383

Zusammenfassung

Clientcomputer mit Microsoft Data Access Components (MDAC) Version 2.6 oder höher können mehrere Protokolle oder IPC-Mechanismen (Interprocess Communication) ausprobieren, um Verbindungen mit SQL Server herzustellen.

Weitere Informationen

Die clientseitige Netzwerkbibliothek wurde verbessert, Dbnetlib.dll für MDAC Version 2.6 und höher. Wenn bei MDAC Version 2.6 und höher mehrere Protokolle verfügbar sind und ein Verbindungsversuch mit dem ersten Protokoll fehlschlägt, versucht die Clientanwendung sofort, eines der anderen Protokolle zu verwenden.

Standardmäßig verfügen Clients über TCP und Named Pipes als verfügbare Protokolle. Sie können die Protokollreihenfolge mithilfe des SQL Server Client-Hilfsprogramms ändern. Die Clientanwendung verwendet die Protokolle in der auf dem Clientcomputer angegebenen Reihenfolge. Die Protokollreihenfolge wird am folgenden Registrierungsschlüsselspeicherort unter dem Wert ProtocolOrder gespeichert:

HKLM\Software\Microsoft\MSSQLServer\Client\SuperSocketNetLib

Wenn Sie SQL Server 2005 verwenden, wird die Protokollreihenfolge im Registrierungseintrag ProtocolOrder unter dem folgenden Registrierungsunterschlüssel gespeichert:

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

Wenn auf einem Clientcomputer beispielsweise sowohl TCP als auch Named Pipes verfügbar sind, und die Reihenfolge lautet:

  • TCP
  • Named Pipes

Wenn der Clientcomputer versucht, eine TCP-Verbindung mit dem Server herzustellen, und der Verbindungsversuch einen Rückgabecode ungleich 0 (null) zurückgibt, versucht der Client transparent eine Verbindung mithilfe des nächsten Protokolls in der Liste( Named Pipes). In diesem Szenario kann der Client keine TCP-Verbindung herstellen. Der Client stellt jedoch erfolgreich eine Named Pipes-Verbindung her.

Hinweis

Der Client erhält keinen Fehler, der darauf hinweist, dass das erste Protokoll fehlgeschlagen ist.

Wenn die Clientanwendung das zweite Protokoll verwendet und auch einen Fehler zurückgibt, wird ein Fehler an den Client zurückgegeben.

Wenn Sie einen Alias mit einer der folgenden Methoden erstellen, verwendet die Clientanwendung die Aliasinformationen, um eine Verbindung mit dem Server herzustellen, und verwendet keine zusätzlichen Protokolle.

  • Mithilfe des SQL Server-Clientnetzwerk-Hilfsprogramms
  • Mithilfe von SQL Server-Konfigurations-Manager
  • Beim Erstellen eines ODBC-Datenquellennamens (DSN)

Wenn Sie das Protokoll steuern möchten, das eine Clientanwendung für jeden Verbindungsversuch verwendet, und nicht zulassen möchten, dass der Client mehrere Protokolle ausprobiert, können Sie eine der folgenden Aktionen ausführen:

  • Verwenden Sie das SQL Client Network-Hilfsprogramm oder SQL Server-Konfigurations-Manager, um einen Alias zu erstellen, indem Sie das von Ihnen bevorzugte Protokoll angeben.

  • Geben Sie das Protokoll in Ihrem Verbindungszeichenfolge an. Zum Beispiel:

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

    In diesem Beispiel geben Sie das Netzwerkprotokoll als DBMSSOCNan, was bedeutet, dass Sie das TCP/IP-Protokoll verwenden möchten. Wenn Sie das Protokoll in Ihrem Verbindungszeichenfolge angeben, verwendet Dbnetlib nur das angegebene Protokoll und versucht kein anderes Protokoll. Um nur das Named Pipe-Protokoll zu aktivieren, verwenden Sie eine Verbindungszeichenfolge ähnlich der folgenden:

    DSN=DSNName;SERVER=servername;DATABASE=YourDataBaseName;Network=DBNMPNTW;Address=\\.\pipe\sql\query;UID=YourUID;PWD=YourPassword;
    
  • Verwenden Sie das Hilfsprogramm Clientnetzwerk, um andere Protokolle zu entfernen.

VERWEISE

Beheben von Konnektivitätsfehlern für SQL Server