Teilen über

Programmierrichtlinien

  • Artikel

ODBC-Treiber herunterladen

Die Features für die Programmierung des Microsoft ODBC Driver für SQL Server unter macOS und Linux basieren auf ODBC in SQL Server Native Client (SQL Server Native Client (ODBC)). SQL Server Native Client basiert auf ODBC in Windows Data Access Components (Referenz für ODBC-Programmierer).

Eine ODBC-Anwendung kann Multiple Active Result Sets (MARS) und andere SQL Server-spezifische Features verwenden, indem /usr/local/include/msodbcsql.h nach den unixODBC-Headern (sql.h, sqlext.h, sqltypes.h und sqlucode.h) eingefügt wird. Verwenden Sie anschließend die gleichen symbolischen Namen für SQL Server-spezifische Elemente, die Sie auch in Ihrer Windows-ODBC-Anwendung verwenden würden.

Verfügbare Funktionen

Die folgenden Abschnitte aus der SQL Server Native Client Dokumentation für ODBC (SQL Server Native Client (ODBC)) sind gültig, wenn der ODBC-Treiber unter macOS und Linux verwendet wird:

Nicht unterstützte Funktionen

Die Funktionsweise der folgenden Funktionen wurde im ODBC-Treiber für macOS und Linux nicht überprüft:

Die folgenden Funktionen stehen im ODBC-Treiber für macOS und Linux nicht zur Verfügung:

  • Verteilte Transaktionen (das Attribut SQL_ATTR_ENLIST_IN_DTC wird nicht unterstützt)
  • Datenbankspiegelung
  • FILESTREAM
  • Leistungsprofilerstellung des ODBC-Treibers, erläutert in SQLSetConnectAttr, sowie die folgenden 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-Intervall-Typen, wie z.B. SQL_C_INTERVAL_YEAR_TO_MONTH (dokumentiert in -Datentypbezeichnungen und Deskriptoren), werden derzeit nicht unterstützt.
  • Der Wert SQL_CUR_USE_ODBC des Attributs SQL_ATTR_ODBC_CURSORS der Funktion SQLSetConnectAttr.

Zeichensatzunterstützung

Für ODBC-Treiber 13 und 13.1 müssen die SQLCHAR-Daten die UTF-8-Codierung aufweisen. Es werden keine weiteren Codierungen unterstützt.

Für ODBC-Treiber 17 werden die folgenden Zeichensätze bzw. Codierungen für SQLCHAR-Daten unterstützt:

Hinweis

Aufgrund von Unterschieden bei iconv in musl und glibc werden viele dieser Gebietsschemas unter Alpine Linux nicht unterstützt.

Weitere Informationen finden Sie unter Functional differences from glibc (Funktionsbezogene Unterschiede zu glibc).

Name BESCHREIBUNG
UTF-8 Unicode
CP437 MS-DOS-Latin-US
CP850 MS-DOS-Latin-1
CP874 Lateinisch/Thailändisch
CP932 Japanisch (Shift_JIS)
CP936 Chinesisch (vereinfacht) (GBK)
CP949 Koreanisch, EUC-KR
CP950 Chinesisch (traditionell) (Big5)
CP1251 Kyrillisch
CP1253 Griechisch
CP1256 Arabisch
CP1257 Baltisch
CP1258 Vietnamesisch
ISO-8859-1 / CP1252 Latin-1
ISO-8859-2 / CP1250 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 / CP1255 Hebräisch
ISO-8859-9 / CP1254 Türkisch
ISO-8859-13 Latin-7
ISO-8859-15 Latin-9

Wenn die Verbindung hergestellt wird, ermittelt der Treiber das aktuelle Gebietsschema des Prozesses, in dem er geladen wurde. Wenn eine der oben aufgeführten Codierungen verwendet wird, verwendet der Treiber diese Codierung für SQLCHAR-Daten (schmale Zeichen). Andernfalls wird standardmäßig die UTF-8-Codierung verwendet. Da alle Prozesse standardmäßig im Gebietsschema „C“ gestartet werden (und der Treiber daher standardmäßig die UTF-8-Codierung verwendet), sollte die Funktion setlocale zum ordnungsgemäßen Festlegen des Gebietsschemas verwendet werden, bevor die Verbindung hergestellt wird. Hierzu muss entweder das Gebietsschema explizit festgelegt oder eine leere Zeichenfolge (z. B. setlocale(LC_ALL, "")) verwendet werden, um die Gebietsschemaeinstellungen der Umgebung zu verwenden.

Daher werden Benutzern des ODBC-Treibers 17, die ein Upgrade von Version 13 oder 13.1 ausgeführt haben, in herkömmlichen Linux- oder macOS-Umgebungen keine Unterschiede auffallen, wenn die UTF-8-Codierung verwendet wird. Allerdings müssen Anwendungen, für die mithilfe von setlocale() eine andere Codierung aus der obigen Liste festgelegt wurde, diese Codierung anstelle der UTF-8-Codierung für Daten für und aus dem Treiber verwenden.

SQLWCHAR-Daten müssen UTF-16LE (Little Endian) sein.

Wenn ein SQL-Typ mit schmalen Zeichen wie SQL_VARCHAR festgelegt ist und Eingabeparameter mit SQLBindParameter eingebunden werden, konvertiert der Treiber die bereitgestellten Daten aus der Codierung des Clients in die SQL Server-Standardcodierung (in der Regel Codepage 1252). Für Ausgabeparameter konvertiert der Treiber die in den Sortierungsinformationen festgelegte Codierung, die den Daten zugeordnet ist, in die Codierung des Clients. Es ist jedoch Datenverlust möglich. Zeichen der Quellcodierung, die nicht in der Zielcodierung angezeigt werden können, werden in Fragezeichen („?“) konvertiert.

Legen Sie einen Unicode-SQL-Zeichentyp wie SQL_NVARCHAR fest, um diese Datenverluste beim Einbinden von Eingabeparametern zu vermeiden. In diesem Fall konvertiert der Treiber die Codierung des Clients in die UTF-16-Codierung, die alle Unicode-Zeichen darstellen kann. Darüber hinaus muss die Zielspalte oder der Zielparameter auf dem Server auch entweder einem Unicode-Typ (nchar, nvarchar, ntext) oder einer Sortierung bzw. Codierung entsprechen, die alle Zeichen der ursprünglichen Quelldaten darstellen kann. Legen Sie einen Unicode-SQL-Typ und entweder einen Unicode-C-Typ (SQL_C_WCHAR), wodurch der Treiber die Daten in der UTF-16-Codierung zurückgibt, oder einen schmalen C-Typ fest, und stellen Sie sicher, dass die Codierung des Clients alle Zeichen der Quelldaten darstellen kann (dies wird mit der UTF-8-Codierung immer gewährleistet), um Datenverlust bei Ausgabeparametern zu vermeiden.

Weitere Informationen zur Sortierung und Codierung finden Sie unter Sortierung und Unicode-Unterstützung.

Zwischen Windows und mehreren Versionen der iconv-Bibliothek unter Linux und macOS gibt es einige Unterschiede bei der Konvertierung der Codierung. Textdaten in der Codepage 1255 (Hebräisch) verfügen über einen Codepunkt (0xCA), der sich bei der Konvertierung in Unicode anders verhält. Unter Windows wird das Zeichen in den UTF-16-Codepunkt 0x05BA konvertiert. Unter macOS und Linux wird es bei libiconv-Versionen vor Version 1.15 in 0x00CA konvertiert. Zeichen, die unter Linux mit iconv-Bibliotheken hinzugefügt werden, welche die Revision von Big5/CP950 (namens BIG5-2003) von 2003 nicht unterstützen, werden nicht ordnungsgemäß konvertiert. In der Codepage 932 (Japanisch, Shift_JIS) unterscheidet sich das Ergebnis der Decodierung von Zeichen, die nicht ursprünglich im Codierungsstandard definiert wurden, ebenfalls. Zum Beispiel wird das Byte 0x80 unter Windows in U+0080 konvertiert, jedoch kann es je nach iconv-Version unter Linux und macOS auch in U+30FB konvertiert werden.

Im ODBC-Treiber 13 und 13.1 werden Daten beschädigt, wenn UTF-8-Mehrbytezeichen oder UTF-16-Ersatzzeichen auf SQLPutData-Puffer aufgeteilt werden. Für das Streamen von SQLPutData verwenden Sie Puffer, die nicht mit partiellen Zeichencodierungen enden. Diese Einschränkung wurde mit dem Version 17 des ODBC-Treibers entfernt.

OpenSSL

Ab Version 17.4 lädt der Treiber OpenSSL dynamisch, sodass diese Software auf Systemen mit Version 1.0 oder 1.1 ausgeführt werden kann, ohne dass separate Treiberdateien erforderlich sind. Ab Version 17.9 unterstützt der Treiber OpenSSL 3.0 zusätzlich zu den vorherigen Versionen. Wenn mehrere OpenSSL-Versionen vorhanden sind, versucht der Treiber, die neueste zu laden.

Treiberversion Unterstützte OpenSSL-Versionen
17.4+ 1.0, 1.1
17.9, 18.0+ 1.0, 1.1, 3.0

Hinweis

Es können Konflikte auftreten, wenn die Anwendung, die den Treiber verwendet (oder eine ihrer Komponenten), mit einer anderen Version von OpenSSL verknüpft ist oder dynamisch eine andere Version von OpenSSL lädt. Wenn im System mehrere OpenSSL-Versionen vorhanden sind und eine Anwendung OpenSSL verwendet, müssen Sie unbedingt sicherstellen, dass die von der Anwendung und vom Treiber geladene Version übereinstimmen. Fehler könnten den Arbeitsspeicher beeinträchtigen, daher macht sich ein solcher Konflikt möglicherweise nicht auf offensichtliche oder konsistente Weise bemerkbar.

Alpine Linux

Zum Zeitpunkt der Erstellung dieser Dokumentation beträgt die Standardstapelgröße in MUSL 128K. Dies ist für die grundlegenden ODBC-Treiberfunktionen ausreichend, aber je nach Zweck der Anwendung kann dieser Grenzwert schnell überschritten werden – insbesondere dann, wenn der Treiber aus mehreren Threads aufgerufen wird. Es empfiehlt sich, eine ODBC-Anwendung unter Alpine Linux mit -Wl,-z,stack-size=<VALUE IN BYTES> zu kompilieren, um die Stapelgröße zu erhöhen. Zur Referenz: Die Standardstapelgröße in den meisten GLIBC-Systemen beträgt 2 MB.

Weitere Hinweise

  • Sie können eine dedizierte Administratorverbindung (DAC) herstellen, indem Sie die SQL Server-Authentifizierung und host,portverwenden. Ein Mitglied der Sysadmin-Rolle muss zunächst den DAC-Port ermitteln. Weitere Informationen dazu finden Sie unter Diagnoseverbindung für Datenbankadministratoren. Wenn beispielsweise der DAC-Port „33000“ ist, können Sie mit sqlcmd wie folgt eine Verbindung herstellen:

    sqlcmd -U <user> -P <pwd> -S <host>,33000

    Hinweis

    DAC-Verbindungen müssen SQL Server-Authentifizierung verwenden.

  • Der UnixODBC-Treiber-Manager gibt „ Attribut-/Optionsbezeichner ungültig“ für alle Anweisungsattribute zurück, wenn sie über SQLSetConnectAttr übergeben werden. Wenn SQLSetConnectAttr einen Anweisungsattributwert erhält, führt dies unter Windows dazu, dass der Treiber diesen Wert für alle aktiven Anweisungen festlegt, die dem Verbindungshandle untergeordnet sind.

  • Bei Verwendung des Treibers mit Anwendungen mit sehr vielen Threads kann die Handlevalidierung von unixODBC zu einem Leistungsengpass führen. In solchen Szenarien lässt sich durch Kompilieren von unixODBC mit der Option --enable-fastvalidate eine höhere Leistung erzielen. Beachten Sie jedoch, dass diese Option bei Anwendungen, die ungültige Handles an ODBC-APIs übergeben, zu einem Absturz führen kann, anstatt SQL_INVALID_HANDLE-Fehler zurückzugeben.

Weitere Informationen

Häufig gestellte Fragen
Bekannte Probleme in dieser Version des Treibers
Versionsanmerkungen