Programmierrichtlinien

ODBC-Treiber herunterladen

Dieser Artikel beschreibt Programmierüberlegungen für Anwendungen, die den Microsoft ODBC Driver für SQL Server unter Linux oder macOS verwenden. Einige Links verweisen auf SQL Server Native Client-Material. Diese Seiten liefern historischen Kontext zur API.

Wählen Sie eine Treiberversion

Verwenden Sie Microsoft ODBC Driver 18 für SQL Server, die aktuelle Treiberreihe, für neue Entwicklungen. Microsoft ODBC Driver 17 für SQL Server wird weiterhin für Anwendungen unterstützt, die ihn bereits einsetzen, wie im Support-Lebenszyklus beschrieben. ODBC Driver 13, der 2017 mit SQL Server ausgeliefert wurde, ist für erweiterten Support bis zum 12. Oktober 2027 berechtigt, nur im Rahmen einer verlängerten Supportvereinbarung.

Gib den installierten Treibernamen, der in geschweifte Klammern eingeschlossen ist, in deinem Verbindungszeichenfolge an:

Driver={ODBC Driver 18 for SQL Server}
Driver={ODBC Driver 17 for SQL Server}

In einem Datenquellennamen (DSN) in odbc.ini verwenden Sie den Namen ohne geschweifte Klammern, zum Beispiel Driver = ODBC Driver 18 for SQL Server. Für die DSN-Syntax siehe Schlüsselwörter für Verbindungszeichenfolgen und Datenquellennamen (DSNs).

Zu versionsspezifischen Verbindungseinstellungen siehe Unterschiede zwischen Hauptversionen. Informationen zu Supportterminen und zur Betriebssystemkompatibilität finden Sie unter Support-Lebenszyklus und Systemanforderungen.

Anwendung erstellen

Zu Header-Speicherorten, einschließlich Reihenfolge, Compiler-Befehlen, Bibliotheksnamen und einem C++-Beispiel, siehe Develop C and C++ applications with the ODBC driver und Connect and query with C++ and ODBC.

Eine ODBC-Anwendung kann Multiple Active Result Sets (MARS) und andere SQL Server-spezifische Funktionen verwenden, indem sie sql.h nach den unixODBC-Headern (sqltypes.h, sqlucode.h, msodbcsql.h und sqlext.h) einfügt. Verwenden Sie dieselben symbolischen Namen für SQL Server-spezifische Items, die Sie auch in Windows ODBC-Anwendungen verwenden.

Treiberfunktionen finden

Beginnen Sie für die Standard-Anwendungsprogrammierschnittstelle (API) mit der ODBC Programmer's Reference. Dann nutze die aktuelle Treiberdokumentation für treiberspezifisches Verhalten.

Die Übersicht des Microsoft ODBC-Treibers für SQL Server verlinkt auf die Treiberdokumentation. Die folgenden Artikel zum SQL Server Native Client bieten API-Kontext für Anwendungen, die den Treiber unter Linux und macOS verwenden:

Limitations

Die folgenden Funktionen wurden im ODBC-Treiber unter Linux und macOS nicht darauf überprüft, korrekt zu funktionieren:

Nicht unterstützte Funktionen

Die folgenden Funktionen sind im ODBC-Treiber unter Linux und macOS nicht verfügbar:

  • Verteilte Transaktionen über das SQL_ATTR_ENLIST_IN_DTC Attribut. Der Treiber unterstützt XA-Transaktionen über den Microsoft Distributed Transaction Coordinator (DTC). Weitere Informationen finden Sie unter Verwenden von XA-Transaktionen mit DTC.

  • Datenbankspiegelung

  • FILESTREAM.

  • Die Profilerstellung der ODBC-Treiberleistung, behandelt in SQLSetConnectAttr, sowie diese leistungsbezogenen Verbindungsattribute:

    • SQL_COPT_SS_PERF_DATA
    • SQL_COPT_SS_PERF_DATA_LOG
    • SQL_COPT_SS_PERF_DATA_LOG_NOW
    • SQL_COPT_SS_PERF_QUERY
    • SQL_COPT_SS_PERF_QUERY_INTERVAL
    • SQL_COPT_SS_PERF_QUERY_LOG
  • SQLBrowseConnect vor Version 17.2.

  • C-Intervalltypen wie SQL_C_INTERVAL_YEAR_TO_MONTH sind in Data Type Identifiers and Descriptors dokumentiert.

  • Der Wert des Attributs SQL_ATTR_ODBC_CURSORS von SQLSetConnectAttr.

Zeichendaten verarbeiten

Unter Linux und macOS verwenden Sie UTF-16-Puffer SQLWCHAR mit ODBC-Wide-Character-APIs anstelle des nativen wchar_t Typs. Die Treiberschnittstelle verwendet 16-Bit-Codeeinheiten.

Charakterkodierungen

Für ODBC Driver 13 und 13.1 müssen Sie UTF-8 für SQLCHAR Daten verwenden. Diese Versionen unterstützen keine weiteren Codierungen.

Ab ODBC Driver 17 werden folgende Zeichensätze und Kodierungen für SQLCHAR Daten unterstützt:

Hinweis

Aufgrund der Unterschiede iconv zwischen musl und glibc werden viele dieser Locales auf Alpine Linux nicht unterstützt. Weitere Informationen finden Sie unter Funktionelle Unterschiede zu glibc.

Name BESCHREIBUNG
UTF-8 Unicode
CP437 MS-DOS-Latin-US
CP850 MS-DOS-Latin-1
CP874 Lateinisch/Thailändisch
CP932 Japanisch (Windows-Codepage 932)
CP936 Chinesisch (vereinfacht) (GBK)
CP949 Koreanisch (Windows-Codepage 949)
CP950 Chinesisch (traditionell) (Big5)
CP1250 Mitteleuropäisch
CP1251 Kyrillisch
CP1252 Westeuropäischer
CP1253 Griechisch
CP1254 Türkisch
CP1255 Hebräisch
CP1256 Arabisch
CP1257 Baltisch
CP1258 Vietnamesisch
ISO-8859-1 Latin-1
ISO-8859-2 Latin-2
ISO-8859-3 Latin-3
ISO-8859-4 Latin-4
ISO-8859-5 Lateinisch/Kyrillisch
ISO-8859-6 Lateinisch/Arabisch
ISO-8859-7 Lateinisch/Griechisch
ISO-8859-8 Hebräisch
ISO-8859-9 Türkisch
ISO-8859-13 Latin-7
ISO-8859-15 Latin-9

Wenn du dich verbindest, erkennt der Treiber das aktuelle Gebietsschema des Prozesses, in den er geladen ist. Wenn das Gebietsschema eine der aufgeführten Codierungen verwendet, verwendet der Treiber diese Kodierung für SQLCHAR (schmale Zeichen-)Daten. Andernfalls wird standardmäßig UTF-8 verwendet. Prozesse starten standardmäßig im C Locale, was dazu führt, dass der Treiber standardmäßig UTF-8 verwendet. Wenn eine Anwendung eine der aufgeführten Codierungen benötigt, rufen Sie setlocale vor dem Verbinden auf. Geben Sie das Gebietsschema explizit an, oder verwenden Sie eine leere Zeichenkette (zum Beispiel setlocale(LC_ALL, "")), um die Gebietsschemaeinstellungen der Umgebung zu verwenden.

In einer typischen Linux- oder macOS-Umgebung, in der die Kodierung UTF-8 ist, werden Nutzer von ODBC Driver 17, die von 13 oder 13.1 upgraden, keine Unterschiede feststellen. Anwendungen, die über setlocale eine gelistete Nicht-UTF-8-Codierung verwenden, müssen diese Codierung für Daten zum und vom Treiber anstelle von UTF-8 verwenden.

Für die Daten musst du UTF-16LE (Little Endian) verwenden.

Wenn Sie Eingabeparameter mit SQLBindParameter binden und einen schmalen Zeichen-SQL-Typ wie SQL_VARCHAR angeben, konvertiert der Treiber die bereitgestellten Daten aus der Client-Codierung in die serverseitige Codierung für diesen Parameter. Die Kodierung hängt von der Kollation ab; es ist nicht immer Codepage 1252. Für Ausgabeparameter konvertiert der Treiber die in den Sortierungsinformationen festgelegte Codierung, die den Daten zugeordnet ist, in die Codierung des Clients. Zeichen in der Quellkodierung, die in der Zielkodierung nicht darstellbar sind, werden in ein Fragezeichen (?) umgewandelt.

Um diesen Datenverlust beim Binden von Eingabeparametern zu vermeiden, gib einen Unicode-SQL-Zeichentyp wie SQL_WVARCHAR. Der Treiber wandelt die Client-Codierung in UTF-16 um, das alle Unicode-Zeichen darstellen kann. Die Zielspalte oder der Parameter muss ebenfalls ein Unicode-Typ sein (nchar, nvarchar oder ntext) oder ein Typ mit einer Kollation oder Codierung, die alle ursprünglichen Quelldaten repräsentieren kann. Für Ausgabeparameter geben Sie einen Unicode-SQL-Typ und entweder einen Unicode-C-Typ (SQL_C_WCHAR), der den Treiber dazu bringt, Daten als UTF-16 zurückzugeben, oder einen schmalen C-Typ mit einer Client-Codierung, die die Quelldaten darstellen kann. UTF-8 kann diese Daten immer darstellen.

Weitere Informationen zu Kollationen und Codierungen finden Sie unter Collation und Unicode-Unterstützung.

Es gibt Konvertierungsunterschiede zwischen Windows- und Linux- oder macOS-Versionen: iconv

  • Für Codepage 1255 wird Byte 0xCA unter Windows in den UTF-16-Codepunkt 0x00CA und unter macOS und Linux mit 0x05BA Versionen vor 1.15 in den UTF-16-Codepunkt libiconv konvertiert.
  • Linux-Bibliotheken iconv ohne die Revision von 2003 von Big5/CP950 (BIG5-2003) konvertieren die in dieser Revision hinzugefügten Zeichen nicht korrekt.
  • Für Codepage 932 (Japanisch, Shift-JIS) unterscheidet sich die Dekodierung von Zeichen, die im Codierungsstandard nicht definiert sind. Zum Beispiel konvertiert Byte 0x80 unter Windows in U+0080 und könnte je nach iconv Version zu U+30FB unter Linux und macOS werden.

In ODBC Driver 13 und 13.1 führt das Aufteilen von UTF-8-Multibyte-Zeichen oder UTF-16-Surrogates über SQLPutData Puffer hinweg zu Datenkorruption. Verwende Streaming-Puffer, die nicht in teilweisen Zeichenkodierungen enden. Diese Einschränkung wurde in ODBC Driver 17 entfernt.

Für Hinweise zur Zeichenkodierung, Konvertierung, Parameterbindung und Puffergröße siehe Bekannte Probleme.

OpenSSL

Ab ODBC Driver 17.4 lädt der Treiber OpenSSL dynamisch, was es ermöglicht, auf Systemen mit Version 1.0 oder 1.1 ohne separate Treiberdateien zu laufen. Ab Version 17.9 unterstützt der Treiber OpenSSL 3.0 zusätzlich zu den vorherigen Versionen. Wenn mehrere Versionen von OpenSSL vorhanden sind, versucht der Treiber, eine unterstützte Version aus seinen Bibliothekssuchpfaden zu laden.

Treiberversion Unterstützte OpenSSL-Versionen
17.4 bis 17.8 1.0, 1.1
17.9 und spätere 17.x-Versionen sowie alle Driver 18-Versionen 1.0, 1.1, 3.0

OpenSSL 4 wird nicht unterstützt. Auf macOS kann ein Homebrew-Link openssl, der auf OpenSSL 4 verweist, verhindern, dass der Treiber OpenSSL lädt, selbst wenn OpenSSL 3 installiert ist. Überprüfen Sie den Bibliothekspfad sowie die installierten Versionen.

Hinweis

Ein potenzieller Konflikt könnte entstehen, wenn die Anwendung, die den Treiber verwendet, oder eine ihrer Komponenten mit einer anderen Version von OpenSSL linkt oder diese dynamisch lädt. Wenn mehrere OpenSSL-Versionen auf dem System vorhanden sind und die Anwendung sie nutzt, stellen Sie sicher, dass die von der Anwendung geladene Version und der Treiber übereinstimmen. Die Fehler könnten den Speicher korrumpieren und zeigen sich möglicherweise nicht auf offensichtliche oder konsistente Weise.

Alpine Linux

Die Standard-Stackgröße für neue Threads in musl beträgt 128 KB, es sei denn, die ausführbare Datei verlangt eine größere Standardgröße. Ein Thread kann diese Grenze überschreiten, wenn er den Treiber aufruft. Verknüpfe eine ODBC-Anwendung unter Alpine Linux mit -Wl,-z,stack-size=<size_in_bytes>, um einen größeren Standard-Thread-Stack anzufordern. Anwendungen, die Threads mit einer expliziten Stackgröße erstellen, müssen ebenfalls eine angemessene Größe für diese Threads wählen.

Der Stack des Hauptthreads und der Standardstack für neue Threads sind nicht die gleiche Einstellung. Auf glibc Systemen folgt der Standard für neue Threads normalerweise dem Stack-Ressourcenlimit des Prozesses, mit einem architekturspezifischen Rückfallback, wenn dieses Limit unbegrenzt ist. Gehen Sie nicht von einem festen 2-MB-Standard auf Linux-Systemen aus.

Zusätzliche Hinweise

Um eine dedizierte Administratorverbindung (DAC) aus einer ODBC-Anwendung herzustellen, setzen Sie Server=tcp:<server>,<dac_port> in Ihrer Verbindungszeichenfolge. Verwenden Sie den entdeckten DAC-Port, nicht den regulären Verbindungsport der Instanz. Zum Beispiel, wenn der DAC-Port 33000 ist, setzen Sie Server=tcp:<server>,33000. Diese Verbindungsstring-Fragmente spezifizieren nur den Endpunkt, nicht die Authentifizierung. Konfigurieren Sie die Authentifizierung und Serverzertifikatsvalidierung getrennt.

Der Login muss Mitglied der sysadmin Serverrolle sein. Der Fernzugriff erfordert, dass die Option für entfernte Admin-Verbindungen des Servers aktiviert ist. Für Zugriffsanforderungen, Serverkonfiguration und Kommandozeilenverwaltungsverfahren siehe Diagnostische Verbindung für Datenbankadministratoren. Für Port-Entdeckung siehe DAC-Port.

Der unixODBC-Treibermanager verarbeitet Anweisungsattribute SQLSetConnectAttr auf dieselbe Weise wie der Windows Driver Manager. ODBC 2.x Anweisungsoptionen wie SQL_ATTR_QUERY_TIMEOUT und SQL_ATTR_MAX_ROWSgelten für bestehende und neue Anweisungen auf der Verbindung. ODBC 3.x nur für Anweisungen geltende Attribute, wie SQL_ATTR_ROW_ARRAY_SIZE und SQL_ATTR_PARAMSET_SIZE, geben SQLSTATE HY092 zurück. Attribute, die sowohl auf Verbindungs- als auch auf Anweisungsebene definiert sind, wie SQL_ATTR_METADATA_ID, können auf beiden Ebenen gesetzt werden. Das Setzen von Statement-only-Attributen auf Verbindungsebene ist in ODBC 3.x veraltet, also rufen Sie stattdessen SQLSetStmtAttr auf. Weitere Informationen finden Sie unter SQLSetConnectAttr-Funktion.

In stark multithreadeten Anwendungen kann die unixODBC-Handle-Validierung zu einem Leistungsengpass werden. Das Kompilieren von unixODBC mit --enable-fastvalidate könnte die Leistung verbessern. Diese Option könnte jedoch dazu führen, dass Anwendungen, die ungültige Handles an ODBC-APIs weitergeben, abstürzen, anstatt SQL_INVALID_HANDLE zurückzugeben.

Für Plattforminstallations- und Konfigurationsschritte siehe: