Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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:
- Kommunikation mit SQL Server (ODBC)
- Verbindungs- und Abfragetimeout-Unterstützung
- Cursoren
- Datum/Uhrzeit-Verbesserungen (ODBC)
- Ausführung von Abfragen (ODBC)
- Umgang mit Fehlern und Nachrichten
- Kerberos-Authentifizierung
- Große benutzerdefinierte Common-Language-Laufzeittypen (CLR) (ODBC)
- Durchführung von Transaktionen (ODBC). Für verteilte Transaktionen unter Linux und macOS verwenden Sie XA-Transaktionen mit DTC.
- Verarbeitungsergebnisse (ODBC)
- Ausführen gespeicherter Prozeduren
- Unterstützung für Sparse Columns (ODBC)
- Verwendung von Verschlüsselung ohne Validierung
- Tabellenwertparameter
- UTF-8 und UTF-16 für die Befehls- und Daten-API
- Verwendung von Katalogfunktionen
Limitations
Die folgenden Funktionen wurden im ODBC-Treiber unter Linux und macOS nicht darauf überprüft, korrekt zu funktionieren:
- Failover-Clusterverbindung.
- Transparente Netzwerk-IP-Auflösung in Versionen vor ODBC Driver 17.
- Linux- und macOS-ODBC-Driver-Built-In-Diagnostics-(BID)-Verfolgung vor ODBC Driver 17.3.
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_DTCAttribut. 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_DATASQL_COPT_SS_PERF_DATA_LOGSQL_COPT_SS_PERF_DATA_LOG_NOWSQL_COPT_SS_PERF_QUERYSQL_COPT_SS_PERF_QUERY_INTERVALSQL_COPT_SS_PERF_QUERY_LOG
SQLBrowseConnectvor Version 17.2.C-Intervalltypen wie
SQL_C_INTERVAL_YEAR_TO_MONTHsind in Data Type Identifiers and Descriptors dokumentiert.Der Wert des Attributs
SQL_ATTR_ODBC_CURSORSvonSQLSetConnectAttr.
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
0xCAunter Windows in den UTF-16-Codepunkt0x00CAund unter macOS und Linux mit0x05BAVersionen vor 1.15 in den UTF-16-Codepunktlibiconvkonvertiert. - Linux-Bibliotheken
iconvohne 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
0x80unter Windows in U+0080 und könnte je nachiconvVersion 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:
- Installiere den ODBC-Treiber unter Linux.
- Installiere den ODBC-Treiber auf macOS.
- Installiere den unixODBC-Treibermanager.
- Verbindungszeichenfolgen und DSNs konfigurieren.
- Überprüfen Sie die Systemanforderungen.