Wesentliche Versionsunterschiede im Microsoft ODBC Driver für SQL Server

Dieser Artikel beschreibt aktuelle Änderungen zwischen Microsoft ODBC Driver 18 für SQL Server und Version 17. Verwenden Sie es, wenn Sie eine Treiberversion auswählen, eine Anwendung von Version 17 auf Version 18 upgraden oder eine Verbindungszeichenfolge auf beiden Versionen konsistent verhalten müssen.

Die meisten Anwendungen, die von Version 17 auf Version 18 aktualisieren, sind von einer einzigen Änderung betroffen: Verbindungen sind standardmäßig verschlüsselt. Wenn deine Anwendung nach dem Upgrade keine Verbindung mehr hat, lies zuerst das Standard-Verschlüsselungsverhalten .

Wähle Version 17 oder Version 18

Driver 18 ist die aktuelle Hauptversion. Driver 17 wird weiterhin unterstützt, aber Anwendungen, die ihn verwenden, benötigen weiterhin die neueste Minor-Version der Driver-17-Reihe, um Korrekturen zu erhalten. Für Support-Daten und Wartungsregeln siehe Support-Lebenszyklus.

Das Ändern der Hauptversionen bedeutet in der Regel, den Treibernamen oder das von dir ausgewählte Paket zu ändern:

Zusammenfassung der Änderungen

Die Standard- und Validierungszeilen beschreiben gewöhnliche entfernte Verbindungen ohne DSN-EinstellungEncrypt, das SQL_COPT_SS_ENCRYPT Attribut oder die Windows Force Protocol Encryption Override. LocalDB ist kein entferntes TLS-Ziel.

Verschlüsselungsänderungen

Standardverschlüsselungsverhalten

Treiber 17 wird standardmäßig aktiviert Encrypt=no , es sei denn, das Authentication Schlüsselwort wird auf einen anderen none Wert gesetzt oder die Anwendung setzt das SQL_COPT_SS_ACCESS_TOKEN Attribut. Entweder ändert der Standard auf yes. Ein explizite Encrypt=no Formular schaltet die Verschlüsselung immer noch aus. Treiber 18.0.1 und später sind standardmäßig auf Encrypt=yes. Setzen Sie es explizit ein, Encrypt wenn Sie Versionen vergleichen.

Die vollständige Verschlüsselung der Verbindung schützt den Abfragetext und die Ergebnisse sowie den Login. Mit Encrypt=no, kann der Server weiterhin eine vollständige Verbindungsverschlüsselung benötigen. Wenn sowohl Client als auch Server die Verschlüsselung deaktivieren, verwendet die nicht-strenge Verhandlung nur eine Login-Verschlüsselung; dies schützt keine nachfolgenden Anwendungsdaten.

Mit Encrypt=yes;TrustServerCertificate=nowählen beide Treiber die normale Serverzertifikatsvalidierung. Wenn nur der Server eine vollständige Verbindungsverschlüsselung benötigt und TrustServerCertificate=no (der Standard), validiert Treiber 18 das Zertifikat. Im TrustServerCertificate=yes Außer-Strict-Modus überspringt Treiber 18 diese Validierung. Driver 17 validiert nicht allein wegen dieser Serveranforderung. Windows Force Protocol Encryption und interne Zertifikatsvalidierungs-Rückrufpfade werden von diesem Vergleich nicht abgedeckt.

Mit den Standard-Verschlüsselungseinstellungen kann ein Upgrade von Version 17 auf Version 18 ein nicht vertrauenswürdiges Serverzertifikat offenlegen. Wenn Version 18 das Zertifikat ablehnt, solltest du die Zertifikatskette und den Namen diagnostizieren, bevor die Authentifizierungseinstellungen geändert werden.

Lassen Sie Verschlüsselung und Serveridentitätsvalidierung aktiviert:

• Konfigurieren Sie ein gültiges Serverzertifikat und den Trust Store des Clients, sodass der Client seiner ausstellenden Zertifizierungsstelle vertraut. Verbinden Sie sich mit einem Namen im Zertifikat.
• Wenn du dich über ein Alias verbindest, setze HostnameInCertificate einen gültigen Namen im Serverzertifikat. Diese Einstellung repariert keine nicht vertrauenswürdige Zertifikatskette.
• Für Encrypt=Strict, unterstützen ServerCertificate Driver 18.1 und spätere Versionen außerdem das Abgleichen des Serverzertifikats mit einer Zertifikatsdatei. Diese Einstellung pinnt ein Zertifikat; sie gibt keinen Hostnamen an. Überprüfen Sie die Einschränkungen in ODBC DSN und die Verbindungszeichenfolge-Schlüsselwörter, bevor Sie es verwenden.

Wenn eine bestehende Anwendung während eines kontrollierten Kompatibilitätstests die Standardeinstellung der Version 17 verlangt, siehe Verschlüsselungsverhalten der Version 17 wiederherstellen. Encrypt=no Und Encrypt=optional reparieren Sie das Zertifikatsvertrauen nicht, sodass Anwendungsdaten unverschlüsselt bleiben.

Verschlüssele Werte

Version 17 akzeptiert nur yes und no. Version 18 und spätere Versionen akzeptieren diese Werte und fügen drei weitere hinzu:

Strict hat kein Pendant zur Version 17. Es ist der einzige Wert, der TDS 8.0 auswählt, bei dem die Verschlüsselung vor dem Login-Austausch und nicht währenddessen ausgehandelt wird.

Verschlüsselungsverhalten von Version 17 wiederherstellen

Nach Überprüfung der Vertrauenskorrekturen verwenden Sie die folgende Einstellung nur für einen kontrollierten Kompatibilitätstest, der unverschlüsselte Anwendungsdaten erlaubt:

Encrypt=no

Treiber 18 akzeptiert Encrypt=optional diese Einstellung ebenfalls. Keiner der beiden Werte verhindert, dass der Server eine Verschlüsselung verlangt. Stellen Sie die beabsichtigte verschlüsselte Konfiguration nach dem Test wieder her; verwenden Sie deaktivierte Verschlüsselung nicht als Zertifikatsvertrauenslösung.

Upgradeprüfliste

1. Inventar-Verbindungszeichen, DSNs, Paketreferenzen und Deployment-Skripte, die Treiber 17 auswählen.
2. Installieren Sie Treiber 18 in einer Testumgebung, die mit der Produktion übereinstimmt.
3. Ändern Sie das Driver Schlüsselwort in jedem Verbindungszeichenfolge in ODBC Driver 18 for SQL Server, und aktualisieren oder erstellen Sie jedes DSN neu, um Treiber 18 zu verwenden. Die Installation von Treiber 18 wechselt keine bestehenden Verbindungen, weil Verbindungen mit dem Namen Treiber 17 weiterhin Treiber 17 verwenden.
4. Legen Sie Encrypt explizit fest. Encrypt=Mandatory Verwendung mit normaler Zertifikatsvalidierung. Verwenden Encrypt=Strict Sie nur, wenn der Server TDS 8.0 unterstützt, wie zum Beispiel SQL Server 2022 und spätere Versionen. Für Server, die TDS 8.0 nicht unterstützen, verwenden Encrypt=MandatorySie .
5. Für die normale Validierung verbinden Sie sich mit TrustServerCertificate=no und überprüfen Sie die vertrauenswürdige Kette und den akzeptierten Servernamen. Für Treiber 18.1 und spätere Versionen mit Strict-Datei-Pinning wird stattdessen die genaue Übereinstimmung und die Gültigkeitsdaten des Zertifikats überprüft; TrustServerCertificate wird im Strict-Modus ignoriert.
6. Führen Sie die Authentifizierungs-, Abfrage-, Transaktions-, Massenkopien-, Failover- und Wiederholungspfade der Anwendung aus.
7. Überprüfen Sie Diagnosen auf Zertifikatsvalidierungsfehler, bevor Fehler als Authentifizierungs- oder Netzwerkfehler behandelt werden.
8. Lass Treiber 17 installiert und behalte das Inventar von Schritt 1 an, bis die Validierung abgeschlossen ist, damit du zu Version 17 zurückkehren kannst.

Rückgang zu Version 17

Treiber 17 und Treiber 18 werden nebeneinander installiert, sodass du zurückrollen kannst, ohne Treiber 18 zu deinstallieren. Für Download- und Installationsdetails siehe Download ODBC Driver für SQL Server.

1. Bestätigen Sie, dass Treiber 17 auf jedem Client noch installiert ist.
2. Mit dem Inventar aus der Upgrade-Checkliste ändert man das Driver Schlüsselwort in jedem Verbindungszeichenfolge zurück zu ODBC Driver 17 for SQL Server.
3. Aktualisieren oder erstellen Sie jedes DSN neu, um Treiber 17 zu verwenden.
4. Setze Paketreferenzen und Bereitstellungsskripte auf das Treiber-17-Paket zurück, wie zum Beispiel msodbcsql17 unter Linux.
5. Stelle die Encrypt Werte TrustServerCertificate der Anwendung mit Treiber 17 wieder her. Treiber 17 akzeptiert nur yes und no für Encrypt und erkennt Treiber 18-Schlüsselwörter wie HostnameInCertificate oder ServerCertificate, daher werden Werte und für Treiber 18 hinzugefügte Schlüsselwörter entfernt. Ändern Sie die Alias-Schlüsselwörter zurück zu ihren Driver-17-Namen und ersetzen ConnectTimeout Sie sie durch einen SQLSetConnectAttr Aufruf, der setzt SQL_ATTR_LOGIN_TIMEOUT. Für die Abbildung siehe New Verbindungszeichenfolge Keywords.

Validiere den Rollback, bevor du ihn als vollständig behandelst:

• Jede Verbindung meldet Fahrer 17. Ruf SQLGetInfo mit SQL_DRIVER_VER; die Hauptversion ist 17.
• Die Authentifizierungs-, Abfrage-, Transaktions-, Massenkopie-, Failover- und Wiederholungspfade der Anwendung sind erfolgreich.
• Verbindungszeichenketten und DSNs enthalten keine Encrypt Werte oder Schlüsselwörter, die für Treiber 18 hinzugefügt wurden.

Neue Verbindungszeichenfolge-Schlüsselwörter

Version 18 fügt folgende Verbindungszeichenfolge-Schlüsselwörter hinzu, die Version 17 nicht erkennt. Einige davon sind neue Namen für Einstellungen, die Version 17 unter einem anderen Schlüsselwort oder Attribut unterstützt, das in der entsprechenden Spalte Version 17 aufgeführt ist.

MultipleActiveResultSets, WorkstationID, und FailoverPartner sind Aliasnamen, die ODBC-Schlüsselwortnamen mit Eigenschaftsnamen ausrichten Microsoft.Data.SqlClient . Version 18 akzeptiert auch die älteren Namen. Details finden Sie unter Connection string Keyword-Unifikation und ConnectTimeout-Keyword.

Für die vollständige Schlüsselwortreferenz siehe ODBC DSN und Verbindungszeichenfolge Keywords.

Verwandte Inhalte

• ODBC DSN und Verbindungszeichenfolge-Schlüsselwörter
• Microsoft ODBC-Treiber für SQL Server
• Supportlebenszyklus
• Veröffentlichungshinweise für den ODBC-Treiber für SQL Server unter Windows
• Veröffentlichungshinweise für den ODBC-Treiber für SQL Server für Linux und macOS