Problembehandlung für den Microsoft OLE DB-Treiber für SQL Server

Gilt für:SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics SQL-Datenbank in Microsoft Fabric

Nutzen Sie diesen Artikel, um die Ausfallphase einer OLE-Datenbankoperation zu identifizieren, wählen Sie die nächste Prüfung und finden Sie detaillierte Fehlerbehebungsanweisungen. Die Leitlinien verwenden den aktuellen Anbieter, MSOLEDBSQL19. Für versionsspezifische Defekte und Upgrade-Änderungen siehe Bekannte Probleme und wesentliche Versionsunterschiede.

Identifizieren Sie das Symptom

Erfassen Sie die vollständige Fehlerbeschreibung und alle verfügbaren Fehlerdatensätze, bevor Sie die Einstellungen ändern. Eine oberste Ebene HRESULT, wie DB_E_ERRORSOCCURRED, identifiziert die Ursache nicht allein. Zeichnen Sie auf, ob der Fehler beim Laden des Anbieters, beim Öffnen einer Verbindung, beim Ausführen eines Befehls, beim Abrufen von Daten oder beim Ausführen einer Transaktion auftritt.

Symptom	Beginne hier
Der Anbieter kann nicht gefunden werden oder die Klasse ist nicht registriert.	Anbieterregistrierung und Architektur
Der Login schlägt fehl, der Zugriff wird verweigert oder die integrierte Authentifizierung scheitert.	Anmelde- und Authentifizierungsfehler
Die Zertifikatskette ist nicht vertrauenswürdig oder der Zertifikatsname passt nicht überein.	TLS-Zertifikatsfehler
Server oder Instanz kann nicht gefunden werden oder die Verbindung wird abgelehnt.	Netzwerk- und Instanzerkennungsfehler
Parameter versagen, Werte werden abgeschnitten oder Daten können nicht konvertiert werden.	Parameter- und Datenkonvertierungsfehler
Verbindung bricht ab, die Wiederherstellung schlägt fehl oder eine Auszeit läuft ab.	Verbindungsverluste und Auszeiten
Fehlerdetails fehlen, oder Sie benötigen eine Ablaufverfolgung für den Support.	Diagnostik und Nachverfolgung

Bei Verbindungsfehlern vergleichen Sie die Anwendung mit einem Universal Data Link (UDL)-Verbindungstest. Verwenden Sie denselben Computer, Provider, dieselbe Prozessarchitektur, Authentifizierungsidentität, Server, Datenbank und Verschlüsselungseinstellungen. Ein erfolgreicher Test mit einem anderen Anbieter oder einer anderen Identität beweist nicht, dass die Konfiguration der Anwendung funktioniert.

Anbieterregistrierung und Architektur

Fehler wie Provider kann nicht gefunden werden oder REGDB_E_CLASSNOTREG (0x80040154, Klasse nicht registriert) deuten darauf hin, dass der Anbieter vor der SQL Server-Authentifizierung geladen wird.

Überprüfe den Anbieter, den die Anwendung anfordert. MSOLEDBSQL19 und MSOLEDBSQL kennzeichnen unterschiedliche Hauptversionen. Die Installation des aktuellen Treibers ändert nicht die Anbieterauswahl einer Anwendung. Folgen Sie den Migrationsschritten , wenn die Anwendung weiterhin einen anderen Anbieter anfordert.
Überprüfen Sie die Architektur des Prozesses, der die Anwendung hostet. Eine 32-Bit-Anwendung benötigt den 32-Bit-Provider, selbst auf 64-Bit-Windows. Für einen Dienst oder einen geplanten Auftrag prüfen Sie die ausführbare Datei und das Konto, das dieser Host verwendet, nicht nur Ihre Entwicklungsumgebung.
Installiere oder repariere den Treiber mit dem unterstützten Installer auf dem Computer, auf dem die Anwendung läuft. Der x64-Installer enthält sowohl 64-Bit- als auch 32-Bit-Treiber-Binären. Überprüfen Sie die erforderlichen Abhängigkeiten in Install the OLE DB Driver and System Requirements. Kopiere keine Treiberbibliotheken von einem anderen Computer als Ersatz für die Installation.
Wiederholen Sie den UDL-Test mit der passenden Architektur und dem Anbieter. Wenn es funktioniert, die Anwendung den Anbieter aber trotzdem nicht laden kann, vergleiche die effektive Anbieterauswahl und Hostarchitektur der Anwendung mit dem Test.

Wenn der Fehler adal.dll ausdrücklich nennt, überprüfen Sie das bekannte Problem mit der Authentifizierungsbibliothek, anstatt ihn als fehlenden SQL Server-Anbieter zu behandeln.

Unterscheide eine Ablehnung des Server-Logins von einem Scheitern bei der Erlangung von Zugangsdaten oder der Herstellung einer verschlüsselten Verbindung. Lesen Sie den vollständigen Fehlertext, einschließlich etwaiger verschachtelter Providerfehler.

Für den SQL Server-Fehler 18456 bitten Sie den Datenbankadministrator, den entsprechenden Server-Fehler-Logeintrag und den Status zu überprüfen. Überprüfen Sie den Authentifizierungsmodus, den Login-Status, die angeforderte Datenbank und den Datenbankzugriff mit MSSQLSERVER_18456. Gehen Sie nicht davon aus, dass jede Ablehnung des Logins ein falsches Passwort bedeutet.
Für die integrierte Authentifizierung bestätigen Sie die Identität, unter der die Anwendung läuft. Ein Servicekonto oder ein Konto mit geplanten Aufgaben kann sich von dem Benutzer unterscheiden, der die Verbindung erfolgreich getestet hat. Wenn die Nachricht Cannot generate SSPI context enthält, befolgen Sie die Schritte unter Fehlerbehebung für die Security Support Provider Interface (SSPI) und Support für den Service Principal Name (SPN).
Für Microsoft Entra ID prüfen Sie, ob die gewählte Authentifizierungsmethode zur Ausführungsumgebung der Anwendung passt und dass deren Identität Zugriff auf die Zieldatenbank hat. Überprüfen Sie die methodenspezifischen Einstellungen und Zugriffstoken-Einschränkungen in Use Microsoft Entra ID. Kombiniere keinen Zugriffstoken mit widersprüchlichen Authentifizierungs- oder Zugangseigenschaften.
Vergleichen Sie die effektiven Einstellungen mit der korrekten Verbindungszeichenfolge-Keyword-Tabelle. IDBInitialize::Initialize, IDataInitialize::GetDataSource, und ActiveX Data Objects (ADO) verwenden unterschiedliche Schlüsselworttabellen. Schau dir die Tabelle für die Schnittstelle an, die deine Anwendung verwendet.

Der Text Der Name des Zielprinzipals ist falsch kann in verschiedenen Kontexten vorkommen. Wenn Cannot generate SSPI context damit einhergeht, überprüfen Sie die Windows-Authentifizierung und die SPNs. Wenn der Fehler das Zertifikat oder den Verschlüsselungshandshake identifiziert, verwenden Sie den nächsten Abschnitt.

TLS-Zertifikatsfehler

Transport Layer Security (TLS)-Fehler können auftreten, bevor ein Login den SQL Server erreicht. Der aktuelle Treiber ermöglicht standardmäßig eine verpflichtende Verschlüsselung, sodass ein Upgrade ein Zertifikatsvertrauens- oder Namensproblem aufdecken kann, das eine ältere Verbindungskonfiguration nicht erkannt hat.

Für Die Zertifikatskette wurde von einer nicht vertrauenswürdigen Autorität ausgestellt, überprüfen Sie das Zertifikat, das SQL Server präsentiert, und die ausstellende Zertifikatskette, der der Client-Computer vertraut. Konfigurieren Sie ein gültiges Serverzertifikat und installieren Sie die erforderlichen vertrauenswürdigen Root- und Zwischenzertifikate über den Zertifikatsverwaltungsprozess Ihrer Organisation.
Bei einer Nichtübereinstimmung des Zertifikatnamens vergleichen Sie den Namen des Servers oder Listeners, den die Anwendung verwendet, mit den Namen im Zertifikat. Verwenden Sie ein Zertifikat, das den beabsichtigten Verbindungsnamen abdeckt. Wenn die Anwendung absichtlich einen anderen Verbindungsnamen verwendet, überprüfen Sie die dokumentierte HostNameInCertificate-Eigenschaft, bevor Sie den erwarteten Zertifikatsnamen konfigurieren.
Überprüfen Sie die effektiven Verschlüsselungs- und Validierungseinstellungen, einschließlich der Registrierungseinstellungen. Überprüfen Sie die Verschlüsselungs- und Zertifikatsvalidierungstabellen auf Vorrang und Strict Verhalten. Im Modus Strict validiert der Treiber das Zertifikat, unabhängig von der Einstellung des Trust-Server-Zertifikats.
Wenn der Fehler während der Migration auftrat, prüfen Sie die Fehlerbehebung für Hauptversionen, einschließlich des Werttyps der Verschlüsselungseigenschaft und der Einschränkung bei der Verwendung von ServerCertificate außerhalb des Strict-Modus.

Verwenden Sie Zertifikatanforderungen für SQL Server und Problembehandlung bei nicht vertrauenswürdiger Zertifikatskette für detaillierte Überprüfungen. Halte die Verschlüsselung und Zertifikatsvalidierung in der Produktion aktiviert. Das Deaktivieren eines der beiden behebt kein Problem bei der Zertifikatsbereitstellung.

Netzwerk- und Instanzerkennungsfehler

Bei Server nicht gefunden, Fehler beim Suchen des angegebenen Servers/der angegebenen Instanz oder Fehlern aufgrund verweigerter Verbindung identifizieren Sie den Endpunkt, den die Anwendung zu erreichen versucht.

Überprüfen Sie den Servernamen, den Instanznamen und den konfigurierten Listening-Port beim Datenbankadministrator. Bestätigen Sie, dass der Datenbankdienst läuft und das vorgesehene Protokoll sowie der Listener aktiviert sind. Gehe nicht davon aus, dass jede Instanz auf Port 1433 hört.
Für eine entfernte Transmission Control Protocol (TCP)-Verbindung wird das bekannte Endpunkt mit dem tcp:<server>,<port> Server-Name-Format des Treibers getestet. Behalten Sie die gleichen Authentifizierungs-, Datenbank- und Verschlüsselungseinstellungen bei. Siehe Connection-String-Schlüsselwörter für das Server-Keyword, das auf deine Schnittstelle angewendet wird.
Wenn der explizite Host und Port funktionieren, aber die benannte Instanz nicht, prüfe den SQL Server Browser und die Instanzfindung. Überprüfen Sie den Browser-Dienst und den UDP-Port-1434-Pfad, der für die Browsererkennung verwendet wird.
Wenn auch der explizite Endpunkt fehlschlägt, überprüfen Sie die Auflösung des Domain Name System (DNS), Routing und Firewall-Zugriff auf den tatsächlichen Listening-Port vom Anwendungshost. Folgen Sie netzwerkbezogenen oder instanzspezifischen Verbindungsfehlern , anstatt mehrere Verbindungseinstellungen gleichzeitig zu ändern.

Für einen Verfügbarkeitsgruppen-Listener sollten Sie außerdem die Unterstützung für hohe Verfügbarkeit und Katastrophenwiederherstellung prüfen. Für LocalDB verwenden Sie die LocalDB-Unterstützung , um die lokale Instanz und den Benutzerkontext zu überprüfen, anstatt entfernte TCP-Discovery-Schritte anzuwenden.

Parameter- und Datenkonvertierungsfehler

Wenn die Verbindung geöffnet wird, aber die Befehlsausführung oder die Datenabruf fehlschlägt, reduzieren Sie die Reproduktion auf den fehlerhaften Befehl und den Wert. Bewahren Sie beim Austausch sensibler Daten den ursprünglichen Datentyp, die Länge, den Nullstatus und die Zeichenkodierung.

Vergleichen Sie jeden ? Parametermarker mit seinem Bindungsordinal, seiner Richtung und seinen Metadaten. Wenn Sie verwenden ICommandWithParameters::SetParameterInfo, passen Sie den SQL-Quellcode dem Befehl oder der gespeicherten Prozedur zu. Gehen Sie nicht davon aus, dass Metadaten der Parameter immer automatisch abgeleitet werden. Überprüfen Sie die Kommandoparameter hinsichtlich Ableitungsbeschränkungen und Verhalten der Ausgabeparameter.
Prüfen Sie den Bindungsstatus der Accessoren sowie Status und Länge jedes zurückgegebenen Werts, nicht nur den Gesamtstatus HRESULT. Bei Fehlern beim Festlegen von Eigenschaften überprüfen Sie das dwStatus jeder Eigenschaft. Eine Rückgabe mit Teilerfolg wie DB_S_ERRORSOCCURRED kann eine Prüfung des Statusarrays erfordern, selbst wenn kein Fehlerobjekt verfügbar ist. Siehe Rückgabecodes.
Für die Umwandlung oder Trunkierung vergleichen Sie den Typ und die Größe des Konsumentenpuffers mit den tatsächlichen Spalten- oder Parametermetadaten. Überprüfen Sie die Genauigkeit und Skalierung für numerische Werte, gültige Bereiche und Bruchteile von Sekunden für Datums-/Zeitwerte sowie Bytelängen für Zeichenpuffer. Untersuchen Sie DBSTATUS_E_CANTCONVERTVALUE, und behandeln Sie DBSTATUS_S_TRUNCATED nicht als vollständigen Wert. Verwenden Sie Datentyp-Mapping, Zeilenabruf sowie Datums- und Zeitumwandlungen für die geltenden Regeln.
Wenn gebundene Ausgabeparameter scheinbar fehlen, arbeiten Sie die zurückgegebenen Ergebnismengen vollständig ab, bevor Sie sie lesen. Folgen Sie Verwenden von IMultipleResults zum Verarbeiten mehrerer Ergebnissätze. Für gestreamte Ausgabeparameter verbrauchen oder veröffentlichen Sie ausstehende Ströme, bevor Sie das nächste Ergebnis anfordern, wie in Streaming-Unterstützung für Ausgabeparameter beschrieben.

Für ADO-spezifische Zuordnungen lesen Sie ADO mit dem OLE DB-Treiber verwenden und die Authentifizierungsbeschränkungen auf DataTypeCompatibility in Microsoft Entra ID verwenden. Füge keine Kompatibilitätseinstellung hinzu, ohne beide zu überprüfen.

Bei beschädigten Strings mit einfacher Bytebreite in einer sql_variant-Spalte nach einem Treiber-Upgrade lesen Sie vor dem Ändern gespeicherter Daten das bestehende bekannte SSVARIANT-Problem und das Verfahren zur Wiederherstellung durch.

Verbindungsverluste und Auszeiten

Notieren Sie, wann die Verbindung zuletzt funktionierte, welche Operation fehlgeschlagen ist und wie lange diese Operation lief. Unterscheiden Sie diese Fälle, bevor Sie die Einstellungen für einen Neuanlauf oder Auszeit ändern.

Ausfallstadium	Überprüfungen und detaillierte Anleitungen
Öffnen einer Verbindung.	Inspizieren Sie zuerst Provider-, Netzwerk-, Authentifizierungs- und TLS-Fehler. Überprüfen Sie das effektive `DBPROP_INIT_TIMEOUT` oder das entsprechende Verbindungsstichwort. Siehe Problembehandlung bei Zeitüberschreitung der Verbindung.
Ausführen eines Befehls.	Überprüfen Sie `DBPROP_COMMANDTIMEOUT` oder das Befehlszeitlimit der Anwendung. Untersuchen Sie Blockierung und Abfrageleistung mit Query Timeout Troubleshooting. Das Erhöhen des Verbindungs-Timeouts ändert das Timeout des Befehls nicht.
Wiederverwenden einer inaktiven Verbindung.	Überprüfen Sie die Wiederherstellungsbedingungen, die Einstellungen für Wiederholungsversuche und die erwarteten Fehler in der Leerlaufverbindungsresilienz. Die Wiederherstellung kann scheitern, wenn die Befehlszeitzeit abläuft, bevor die Wiederverbindung abgeschlossen ist.
Verbindungsverlust während der Ausführung oder des Commits.	Korrelieren Sie Client- und Serverereignisse, um festzustellen, ob eine Netzwerkunterbrechung, ein Serverneustart oder ein Failover vorliegt. Stellen Sie das Ergebnis des Vorgangs fest, bevor Sie entscheiden, ob ein erneuter Versuch sicher ist.

Die Idle-Verbindungsresilienz bietet weder Wiederholungen des Verbindungsaufbaus noch das automatische erneute Ausführen beliebiger Befehle und Transaktionen. Bei einem bestätigten vorübergehenden Fehler verwenden Sie begrenzte Anwendungswiederholungen mit Verzögerung und protokollieren Sie jeden Versuch. Versuchen Sie nicht wiederholt Provider-Loading-Fehler, abgelehnte Zugangsdaten oder Fehler bei Zertifikatsvalidierung, ohne die Ursache zu korrigieren.

Caution

Wenn eine Verbindung während eines Schreibens oder Commit abbricht, weiß der Client möglicherweise nicht, ob SQL Server die Transaktion ausgeführt hat. Wiederhole den Vorgang nicht blindlings. Überprüfen Sie das Ergebnis oder verwenden Sie ein Anwendungsdesign, das doppelte Effekte verhindert, bevor Sie es erneut versuchen.

Diagnostik und Nachverfolgung

Sammeln Sie Diagnosen am Ausfallpunkt, bevor nicht verwandte Anbieteranrufe die Fehlerinformationen ersetzen.

Erfassen Sie die fehlerhafte Operation, Zeitstempel und Zeitzone, verstrichene Zeit und HRESULT. Für native OLE-Datenbank-Konsumenten werden alle verfügbaren Datensätze über IErrorInfo und IErrorRecordsabgerufen, nicht nur die erste Beschreibung. Fügen Sie SQLSTATE und die native SQL Server-Fehlernummer ein, wenn diese über ISQLErrorInfo verfügbar ist. Siehe Fehlerinformationen abrufen und Details zum SQL Server-Fehler. Für ADO erfassen Sie die Errors Sammlung der Verbindung.
Sammeln Sie die Status pro Eigenschaft, pro Bindung und pro Wert für Methoden, die Fehler auf diese Weise melden. Ein fehlendes Fehlerobjekt bedeutet nicht, dass ein Teilerfolgsergebnis bedenkenlos ignoriert werden kann.
Korrelieren Sie den Clientausfall mit dem Server-Fehlerprotokoll oder den erweiterten Ereignissen. Wenn verfügbar, zeichnen Sie ClientConnectionID und ActivityID auf. Ein Fehler vor der Prelogin kann ohne eine Client-Verbindungskennung auftreten.
Wenn Fehleraufzeichnungen nicht ausreichen, verwenden Sie die Access-Diagnoseinformationen im Extended Events-Logbuch zur Fahrerverfolgung und zur Einrichtung der Korrelation. Sammeln Sie eine begrenzte Spur um die Reproduktion und hören Sie danach auf zu verfolgen.

Wenn Sie eskalieren, fügen Sie die Treiberversion, den angeforderten Provider, die Anwendungs- und Prozessarchitektur, die Serverversion, die Authentifizierungsmethode, die effektiven Verbindungseinstellungen, die Fehlerphase, Fehleraufzeichnungen und eine minimale Reproduktion an. Gib an, ob der passende UDL-Test erfolgreich ist und ob das Problem einen oder mehrere Hosts betrifft.

Entfernen Sie Passwörter, Zugriffstoken und andere Geheimnisse aus Verbindungseinstellungen und Protokollen. Überprüfen Sie Traces auf Anfragetexte und sensible Daten, speichern Sie sie mit eingeschränktem Zugriff und teilen Sie sie nur über einen genehmigten Support-Kanal.

Feedback

War diese Seite hilfreich?

Last updated on 2026-09-23