Programmierrichtlinien

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:

• Kommunikation mit SQL Server (ODBC)
• Verbindungs- und Abfragetimeout-Unterstützung
• Cursor
• Datums-/Uhrzeitverbesserungen (ODBC)
• Ausführen von Abfragen (ODBC)
• Behandlung von Fehlern und Meldungen
• Kerberos-Authentifizierung
• Große benutzerdefinierte CLR-Typen (ODBC)
• Ausführen von Transaktionen (ODBC) (mit Ausnahme der verteilten Transaktionen)
• Verarbeiten von Ergebnissen (ODBC)
• Ausführen gespeicherter Prozeduren
• Unterstützung für Spalten mit geringer Dichte (ODBC)
• Verwenden von Verschlüsselung ohne Überprüfung
• Table valued parameters (Tabellenwertparameter)
• UTF-8 und UTF-16 für die Befehls- und Daten-API
• Verwenden von Katalogfunktionen

Nicht unterstützte Funktionen

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

• Failoverclusterverbindung
• Transparente Netzwerk-IP-Adressauflösung (vor ODBC-Treiber 17)
• BID-Ablaufverfolgung für ODBC-Treiber unter Linux und macOS (vor ODBC-Treiber 17.3)

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:

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.

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