Microsoft OLE DB-Treiber für SQL Server

OLE DB-Treiber herunterladen

Der Microsoft OLE DB-Treiber für SQL Server ist eine eigenständige Datenzugriffs-Anwendungsprogrammierschnittstelle (API), die Teil von OLE DB ist. Es verbindet C- und C++-Anwendungen mit der Microsoft SQL Datenbank-Engine in Azure SQL-Datenbank, SQL-Datenbank in Microsoft Fabric, Azure SQL Managed Instance und in unterstützten Versionen von SQL Server. Microsoft veröffentlichte es erstmals 2018 als Version 18 und integrierte es in SQL Server 2019 (15.x).

MSOLEDBSQL19 ist der aktuelle Fahrer. Es ist im Allgemeinen abwärtskompatibel mit SQL Server Native Client (SNAC) und bietet Funktionen, die über die von SNAC und dem SQL Server OLE DB-Anbieter bereitgestellten hinausgehen, der von Windows Data Access Components (Windows DAC, früher Microsoft Data Access Components oder MDAC) bereitgestellt wird.

Auswählen des Startpunkts

• Um zu entscheiden, ob OLE DB die richtige API für Ihre Anwendung ist, beginnen Sie mit Wann man den OLE DB-Treiber für SQL Server verwendet.
• Um den Treiber zu installieren und mit dem Schreiben von Code zu beginnen, gehe zu Download OLE DB-Treiber für SQL Server, System Requirements und Building applications with OLE DB-Treiber für SQL Server.
• Um mit Azure SQL über kennwortlose Authentifizierung eine Verbindung herzustellen, wechseln Sie zu Using Microsoft Entra ID und Using Verbindungszeichenfolge keywords.
• Um von SQLNCLI oder SQLOLEDB zu wechseln, wechseln Sie zu Aktualisieren einer Anwendung von MDAC auf OLE DB-Treiber für SQL Server und Wesentliche Versionsunterschiede.
• Um den Treiber von ADO zu verwenden, gehe zu Using ADO with OLE DB-Treiber für SQL Server.
• Um ein Verbindungs- oder Abfrageproblem zu diagnostizieren, gehe zu 'Zugriff auf diagnostische Informationen' im erweiterten Ereignisprotokoll und 'Bekannte Probleme'.

Produktionsbasisplan für Azure SQL

Verwenden Sie diesen Codeausschnitt als Ausgangspunkt für eine produktionsorientierte Azure SQL Verbindung. Er lädt den Servernamen und den Datenbanknamen aus der Anwendungskonfiguration, authentifiziert sich mit einer verwalteten Identität, sodass kein Geheimnis in der Verbindungszeichenfolge erscheint, und aktiviert die Verschlüsselung von Tabular Data Stream (TDS) 8.0 mit vollständiger Zertifikatsvalidierung. Es legt ein Verbindungs-Timeout pro Versuch fest und wiederholt bei vorübergehenden Fehlern den Verbindungsversuch mit exponentiellem Backoff und Jitter.

Der C++-Ausschnitt in diesem Artikel lässt der Kürze halber Includes, die COM-Initialisierung und die Hilfsfunktion für die Protokollierung weg.

std::wstring BuildConnectionString(const wchar_t* server, const wchar_t* database) {
    std::wstring cs = L"Provider=MSOLEDBSQL19";
    cs += L";Data Source=tcp:"; cs += server; cs += L",1433";
    cs += L";Initial Catalog="; cs += database;
    cs += L";Authentication=ActiveDirectoryMSI";   // managed identity, no stored secret
    cs += L";Use Encryption for Data=Strict";      // TDS 8.0 with certificate validation
    cs += L";Connect Timeout=30";                  // per-attempt connect timeout, in seconds
    cs += L";Connect Retry Count=3";               // idle connection resiliency, not initial connect
    cs += L";Connect Retry Interval=10";
    return cs;
}

// Transient fault codes documented for Azure SQL, plus the resource governance
// codes. Network termination and timeout errors (64, 233, 258, 10053, 10054,
// 10060) are retried a bounded number of times, which is the documented
// guidance for them. 258 is the code the driver reports for a connect timeout.
// 10053 and 10054 can also mean the encryption handshake failed rather than a
// plain network reset, so read the error text before assuming a network fault.
bool IsTransient(LONG nativeError) {
    switch (nativeError) {
        case 615: case 926: case 4060: case 4221:
        case 10928: case 10929: case 10936:
        case 40197: case 40501: case 40613:
        case 42108: case 42109:
        case 49918: case 49919: case 49920:
        case 40020: case 40143: case 40166: case 40540:   // failover subcodes
        case 64: case 233: case 258:
        case 10053: case 10054: case 10060:
            return true;
        default:
            return false;
    }
}

// Retries only errors that a new connection can clear, with exponential backoff
// plus jitter so that concurrent clients don't retry in lockstep.
HRESULT ConnectWithRetry(IDataInitialize* pDataInit, const std::wstring& connectionString,
                         int maxAttempts, IDBInitialize** ppDbInit) {
    HRESULT hr = E_FAIL;
    *ppDbInit = nullptr;
    for (int attempt = 1; attempt <= maxAttempts; ++attempt) {
        IDBInitialize* pDbInit = nullptr;
        hr = pDataInit->GetDataSource(nullptr, CLSCTX_INPROC_SERVER, connectionString.c_str(),
                                      IID_IDBInitialize, reinterpret_cast<IUnknown**>(&pDbInit));
        if (SUCCEEDED(hr) && SUCCEEDED(hr = pDbInit->Initialize())) {
            Log("INFO", "connected on attempt %d/%d", attempt, maxAttempts);
            *ppDbInit = pDbInit;
            return S_OK;
        }

        // Walks IErrorRecords and returns the first record that carries a real
        // SQL Server error number. Transport and timeout failures report a
        // generic wrapper record first, whose native error is 0. Errors the
        // server returns carry the number on the first record.
        LONG native = LogProviderErrors("connect", hr);
        if (pDbInit) pDbInit->Release();
        if (attempt == maxAttempts || !IsTransient(native)) return hr;

        // Cap the backoff at 64 seconds. This also keeps the shift in range
        // when a caller passes a large maxAttempts.
        int shift = (attempt - 1 < 6) ? attempt - 1 : 6;
        DWORD delayMs = (1UL << shift) * 1000UL + (DWORD)(GetTickCount64() % 500);
        Log("WARN", "retrying in %lu ms (attempt %d/%d)", delayMs, attempt + 1, maxAttempts);
        Sleep(delayMs);
    }
    return hr;
}

Connect Retry Count und Connect Retry Interval aktivieren die Resilienz von Leerlaufverbindungen, wodurch eine Verbindung, die während des Leerlaufs unterbrochen wurde, transparent wiederhergestellt wird. Sie wiederholen den anfänglichen Verbindungsaufbau nicht, weshalb dieses Codebeispiel auch eine Wiederholungslogik auf Anwendungsebene implementiert. Behalte beides.

Dieser Codeausschnitt erstellt seine Verbindungszeichenfolge für IDataInitialize::GetDataSource, das die hier gezeigten Schlüsselwortnamen mit Leerzeichen verwendet, z. B. Use Encryption for Data und Connect Retry Count. IDBInitialize::Initialize und ADO verwenden für dieselben Settings unterschiedliche Bezeichnungen, wie Encrypt zum Beispiel und ConnectRetryCount.

GetDataSource akzeptiert einen Namen aus der falschen Menge, ohne einen Fehler zu erzeugen, und die Einstellung tritt nie in Kraft. Die Verbindung verwendet dann den Treiber-Standard, was ihn schwächen kann. Encrypt=Strict auf diesem Pfad bleibt die Verschlüsselung auf Mandatory , MSOLEDBSQL19sodass die Verbindung TDS 8.0 abbricht und die Verschlüsselung im Cleartext-Prelogin aushandelt, und die Verschlüsselung bleibt vollständig auf MSOLEDBSQL. Nicht in jedem Fall kommt es zu einem Fail-open-Verhalten: Der falsch gesetzte Wert TrustServerCertificate wird auf die gleiche Weise verworfen, sodass die Eigenschaft auf dem Standardwert false bleibt und die Zertifikatsvalidierung aktiviert bleibt.

Verlassen Sie sich nicht darauf, dass ein Fehler einen Fehler aufdeckt. Ein Name, der zu keiner Menge gehört, wie ZzzNotAKeyword, erzeugt einen Invalid Verbindungszeichenfolge attribute Datensatz, aber ein Name aus der falschen Menge erzeugt nichts. Um zu bestätigen, dass eine Einstellung wirksam wurde, lesen Sie die Eigenschaft mit IDBProperties::GetProperties erneut aus, bevor Sie die Verbindung herstellen. Den Schlüsselwortsatz, der zu jeder API gehört, finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit dem OLE DB-Treiber für SQL Server.

OLE DB meldet Diagnoseinformationen über das Fehlerobjekt und nicht allein über das HRESULT, daher sollten Fehler vor einem erneuten Versuch klassifiziert werden. Ein Authentifizierungs- oder Konfigurationsfehler schlägt dann sofort fehl, anstatt das gesamte Wiederversuchsbudget zu verbrauchen.

Weitere Informationen zu den einzelnen Teilen dieser Konfiguration finden Sie unter:

• Verwenden von Verbindungszeichenfolgen-Schlüsselwörtern mit dem OLE DB-Treiber für SQL Server
• Verwenden von Microsoft Entra ID
• Verschlüsselung und Zertifikatüberprüfung
• Widerstandsfähigkeit der Leerlaufverbindung
• OLE DB Driver für SQL Server: Unterstützung für Hochverfügbarkeit und Notfallwiederherstellung

Für den Katalog der Azure SQL Transient Errors siehe Transient Fault Error Codes.

Wichtigste Funktionen

• Microsoft Entra ID-Authentifizierung: Kennwortlose Verbindungen mit verwalteter Identität, Dienstprinzipal sowie interaktiven und integrierten Abläufen.
• Strenge Verschlüsselung: TDS-8.0-Verbindungen mit vollständiger Zertifikatsvalidierung und TLS 1.3 in Version 19.2.0 und späteren Versionen.
• Widerstandsfähigkeit der Leerlaufverbindung: Transparente Wiederherstellung einer Verbindung, die im Leerlauf abgebrochen ist.
• Multiple Active Result Sets (MARS): Mehr als eine ausstehende Anfrage pro Verbindung.
• Massenkopie: Hochdurchsatz-Inserts über die Bulk-Copy-Schnittstellen.
• Tabellenwertige Parameter: Ein gesamter Ergebnissatz, der als einzelner Parameter an den Server übergeben wird.
• Always On-Verfügbarkeitsgruppen: Listenerunterstützung mit MultiSubnetFailover für schnelles Failover.
• UTF-8 und UTF-16 Unterstützung: Zeichendaten in beiden Kodierungen.
• Datenklassifikation: Sensitivitätsmetadaten für klassifizierte Spalten.
• Asynchrone Operationen: Nicht blockierende Datenquellen- und Zeilensatzoperationen.

Erste Schritte

Konfigurieren und Verbinden

Authentifizieren und sichern

Befehle ausführen und Ergebnisse verarbeiten

Arbeiten mit Zeilensätzen und Cursoren

Massenkopieren

Parameter mit Tabellenwert

Arbeit mit großen und binären Daten

Verwaltung von Tabellen, Indizes und gespeicherten Prozeduren

Datentypen

Transaktionen

Diagnostizieren und Problembehandlung

Migration auf den aktuellen Treiber

Es gibt drei Generationen von Microsoft OLE DB-Anbietern für SQL Server. Für neue und bestehende Anwendungen verwenden MSOLEDBSQL19 und bestehende Verbindungsstränge darauf umwandeln. Der OLE-DB-Anbieter wurde nicht mehr als veraltet gekennzeichnet und 2018 erneut veröffentlicht.

Reference

Verwandte Inhalte

• Matrix der unterstützten Treiberfunktionen
• Erläuterung des SNAC-Lebenszyklus