Häufig gestellte Fragen zu ODBC unter Linux und macOS

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.

Die Upgrade-Änderung, die die meisten Anwendungen betrifft, ist, dass Driver 18 die Verbindungen standardmäßig verschlüsselt. Alle Unterschiede siehe Unterschiede zwischen Hauptversionen.

Driver 18 unterstützt folgende Betriebssysteme und Prozessorarchitekturen:

Die unterstützten Betriebssystemversionen ändern sich mit jeder Treiberveröffentlichung. Die versionsspezifische Tabelle finden Sie unter Systemanforderungen.

Der Treiber unter Linux und macOS unterstützt die meisten SQL Server-Funktionen. Es unterstützt keine verteilte Transaktionsanmeldung über die SQL_ATTR_ENLIST_IN_DTC Attribute, Datenbankspiegelung, FILESTREAM oder die Treiber-Performance-Profiling-Attribute. LocalDB ist weder unter Linux noch macOS verfügbar. XA-Transaktionen über den Distributed Transaction Coordinator (DTC) werden ab Driver 17.3 unterstützt. Weitere Informationen finden Sie unter Verwenden von XA-Transaktionen mit DTC. Die vollständige Liste finden Sie unter Einschränkungen.

No. Der Microsoft ODBC-Treiber für SQL Server ist nicht Open Source.

Der Treiber verwendet den unixODBC-Treibermanager. Wenn du Treiber 17 oder 18 mit dem Paketmanager deiner Plattform oder Homebrew installierst, wird unixODBC als Abhängigkeit installiert. Folgen Sie den Schritten für Linux oder macOS.

Baue und führe deine Anwendung unter macOS mit unixODBC statt iODBC aus. Passen Sie die Prozessorarchitektur der Anwendung, des Treibermanagers und des Treibers an. Ein Fehler wie dies incompatible architecture (have 'arm64', need 'x86_64') deutet auf eine Architekturfehlanpassung hin, nicht unbedingt auf den falschen Treibermanager.

Führen Sie odbcinst -q -d aus, um die registrierten Treiber aufzulisten. Die Ausgabe zeigt jeden Treibernamen genau so, wie eine Verbindungszeichenfolge ihn schreiben muss:

[ODBC Driver 18 for SQL Server]

Führe odbcinst -j aus, um die unixODBC-Version und die Pfade von odbcinst.ini anzuzeigen, das Treiber registriert, und odbc.ini, das System- und Benutzerdatenquellennamen (DSNs) enthält:

unixODBC 2.3.11
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/<user>/.odbc.ini

Informationen zum Konfigurieren eines DSN finden Sie unter Verbindungszeichenfolgen und DSNs.

Der Fehler sieht wie folgt aus:

[01000][unixODBC][Driver Manager]Can't open lib 'ODBC Driver 18 for SQL Server' : file not found

Überprüfen Sie diese Ursachen in der Reihenfolge:

1. Der Driver Wert im Verbindungszeichenfolge oder DSN stimmt nicht mit einem registrierten Treibernamen überein. Führe odbcinst -q -d aus und kopiere den Namen genau.
2. Deine Anwendung verwendet andere Konfigurationsdateien als die, die du bearbeitet hast. Führe odbcinst -j aus derselben Umgebung wie die Anwendung aus und überprüfe, welchen Treibermanager die Anwendung lädt. Auf macOS erstellen Sie symbolische Konfigurationslinks nur, wenn die Anwendung sie benötigt, wie in Fehlerbehebung auf macOS beschrieben.
3. Mehr als eine Kopie des unixODBC-Treibermanagers ist installiert, und Ihre Anwendung lädt die falsche Kopie. Führen Sie find /usr -name 'libodbc*.so*' unter Linux aus. Auf macOS führe find /opt/homebrew /usr/local -name 'libodbc*.dylib' aus. Mehrere Pfade allein beweisen nicht, dass mehrere Treibermanager installiert sind: Homebrew-Links können auf dieselbe Bibliothek im Cellar-Verzeichnis verweisen. Überprüfe, welche Bibliothek die Anwendung tatsächlich lädt. Weitere Informationen finden Sie unter „Fehlerbehebung bei Verbindungsproblemen“.

Treiber 18 setzt standardmäßig auf Encrypt=yes. Treiber 17 verwendet standardmäßig nur Encrypt=no, wenn keine nichtleere Authentication Einstellung oder kein Zugriffstoken bereitgestellt wird. Eine nichtleere Authentication-Einstellung, einschließlich Authentication=SqlPassword, oder ein Zugriffstoken ändert die Standardeinstellung von Treiber 17 auf Encrypt=yes. Explizite Verschlüsselungseinstellungen überschreiben diese Standardeinstellungen.

Überprüfen Sie die effektiven Einstellungen in Ihren Verbindungszeichenfolgen-, DSN- und Vorverbindungsattributen, die durch SQLSetConnectAttr festgelegt werden. Zum Beispiel fordern Encrypt=yes in einem DSN oder SQL_COPT_SS_ENCRYPT=SQL_EN_ON die Verschlüsselung an, selbst wenn in der Verbindungszeichenfolge Encrypt fehlt. Stellen Sie Zugriffstoken nur über das SQL_COPT_SS_ACCESS_TOKEN Verbindungsattribut bereit, nicht über ein Verbindungsstring-Schlüsselwort.

Mit Encrypt=yes und TrustServerCertificate=noverschlüsseln beide Treiber die Verbindung und validieren das Serverzertifikat. Mit Encrypt=no validiert Treiber 17 das Zertifikat nicht, während Treiber 18 es validiert, wenn der Server Verschlüsselung und TrustServerCertificate=no erzwingt. Eine Verbindung, die zuvor den Standard von Treiber 17 Encrypt=no verwendete, kann daher mit Treiber 18 gegen einen Server mit selbstsigniertem oder anderweitig nicht vertrauenswürdigem Zertifikat ausfallen. Bei einem selbstsignierten Zertifikat sieht der Fehler Treiber 18 folgendermaßen aus:

[Microsoft][ODBC Driver 18 for SQL Server]SSL Provider: [error:0A000086:SSL routines::certificate verify failed:self-signed certificate]
[Microsoft][ODBC Driver 18 for SQL Server]Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2226722

Bevorzugen Sie ein vertrauenswürdiges Zertifikat oder das Anheften von Zertifikaten. Nutzen Sie diese Optionen:

• Installiere ein Zertifikat auf dem Server, das von einer Zertifizierungsstelle ausgestellt wird, der der Client vertraut. Wenn das Zertifikat vertrauenswürdig ist, sein Name aber nicht mit dem Server Wert übereinstimmt, setze HostNameInCertificate auf den Namen im Zertifikat. HostNameInCertificate ändert nur den erwarteten Namen, sodass ein selbstsigniertes Zertifikat nicht behoben wird.
• Bei Treiber 18.1 und neueren Versionen sowie einem Server, der Tabular Data Stream (TDS) 8.0 unterstützt, legen Sie Encrypt=strict fest und setzen Sie ServerCertificate auf den Pfad einer Kopie des Serverzertifikats. Der Fahrer akzeptiert dann nur genau dieses Zertifikat. ServerCertificate funktioniert nur im strengen Modus.
• Legen Sie Encrypt=no nur fest, wenn Sie unverschlüsselten Anwendungsverkehr akzeptieren, wenn der Server keine Verschlüsselung erzwingt. Dies entspricht dem Standard von Driver 17 nur, wenn keine nichtleere Authentication Einstellung oder Zugriffstoken angegeben ist und keine Verschlüsselungsüberschreibung festgelegt ist. Wenn der Server die Verschlüsselung erzwingt, validiert Treiber 18 das Zertifikat weiterhin, es sei denn, TrustServerCertificate=yes deaktiviert die Validierung.

Weitere Informationen finden Sie unter Standard-Verschlüsselungsverhalten.

Ja. Hol dir ein Kerberos-Ticket mit kinit, dann verbinde dich mit Trusted_Connection=yes in der Verbindungszeichenfolge oder im DSN. Die SQL Server-Instanz benötigt einen registrierten Service Principal Name (SPN). Für Einrichtungsschritte siehe Integrierte Authentifizierung verwenden.

Ja, für Azure SQL-Datenbank, Azure SQL Managed Instance und SQL Server 2022 und spätere Versionen. Um SQL Server einzurichten, auch über Azure Arc, verwenden Sie die Microsoft Entra-Authentifizierung für SQL Server. Unter Linux und macOS unterstützen Driver 17 und neuere Versionen folgende Methoden:

• Verwaltete Identität, mit Authentication=ActiveDirectoryMsi, beginnend mit Treiber 17.3.
• Service Principal, mit Authentication=ActiveDirectoryServicePrincipal, beginnend mit Driver 17.7.
• Integrierte Authentifizierung über Kerberos in einer föderierten Umgebung, mit Authentication=ActiveDirectoryIntegrated, ab Driver 17.6.
• Ein Zugriffstoken, den Ihre Anwendung erhält, das über das Verbindungsattribut SQL_COPT_SS_ACCESS_TOKEN übergeben wird.

ActiveDirectoryInteractiveist nur im Windows-Treiber verfügbar. ActiveDirectoryPassword ist veraltet. Treibergesteuerte Authentifizierung unter Linux und macOS unterstützt keine Szenarien, die bedingten Zugriff erfordern. Wenn Ihre Anwendung ein Zugriffstoken separat erwirbt, regeln die Authentifizierungsbibliothek und die Microsoft Entra ID-Richtlinien diese Tokenbeschaffung. Leite den Token durch SQL_COPT_SS_ACCESS_TOKEN weiter.

Auf Alpine Linux erfordert integrierte Authentifizierung einen libcurl Build mit Unterstützung für den Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO). Überprüfen Sie Ihre installierten libcurl-Funktionen, anstatt davon auszugehen, dass das Standardpaket diese unterstützt.

Für Verbindungszeichenfolgen und Codebeispiele siehe Use Microsoft Entra ID with the ODBC Driver.

Ja. Eine für die ODBC Application Programming Interface (API) geschriebene und gegen unixODBC erstellte Anwendung kann diesen Treiber laden. Um SQL Server-spezifische Funktionen zu verwenden, fügen Sie msodbcsql.h nach den unixODBC-Headern hinzu. Für Compiler-Befehle und Bibliotheksnamen siehe C- und C++-Anwendungen mit dem ODBC-Treiber entwickeln.

Ja. In Mit C++ und ODBC verbinden und abfragen wird ein Beispiel unter Linux, macOS und Windows erstellt und ausgeführt.

Trace-Dateien können sensible Daten enthalten. Erstelle als das Konto, das deine Anwendung ausführt, ein Verzeichnis, auf das nur dieses Konto Zugriff hat:

mkdir -m 700 "$HOME/odbc-trace"

Fügen Sie diese Einstellungen dem [ODBC] Abschnitt von odbcinst.inihinzu. Ersetze /home/<user>/odbc-trace/odbctrace.log durch den absoluten Pfad innerhalb des von dir erstellten Verzeichnisses. Unter macOS verwenden Home-Verzeichnisse typischerweise /Users/<user> statt /home/<user>.

Behalten Sie den vollständigen Pfad der Trace-Datei auf 62 Bytes oder weniger, um eine Trunkierung durch unixODBC zu vermeiden.

[ODBC]
Trace = Yes
TraceFile = /home/<user>/odbc-trace/odbctrace.log

Diese Einstellungen ermöglichen die Ablaufverfolgung von Anwendungen, die diese Treibermanager-Konfiguration verwenden, und die Ablaufverfolgung verlangsamt diese Anwendungen. Verwenden Sie für jedes Anwendungskonto ein separates privates Verzeichnis. Entfernen Sie Trace = Yes, wenn Sie fertig sind, und löschen Sie Trace-Dateien, die Sie nicht mehr benötigen. Für die Nachverfolgung pro Anwendung, siehe Nachverfolgung des Datenzugriffs auf Linux und macOS.

Nutze UTF-16LE (Little Endian) für SQLWCHAR Daten. Verwenden Sie UTF-16-Puffer SQLWCHAR mit den ODBC-Breitzeichen-APIs anstelle des nativen wchar_t Typs, der unter Linux und macOS 32 Bit ist.

Nutze UTF-8 für SQLCHAR Daten. Ab Treiber 17 akzeptiert der Treiber auch eine Reihe von Single-Byte- und Double-Byte-Codepages für SQLCHAR-Daten, wenn das Prozessgebietsschema eine auswählt. Prozesse starten in der C-Locale, sodass der Treiber UTF-8 verwendet, es sei denn, die Anwendung ruft setlocale auf. Für die Liste der Codierungen siehe Zeichendaten verarbeiten.