Najczęściej zadawane pytania dotyczące ODBC na Linuksie i macOS

W przypadku nowych projektów użyj sterownika Microsoft ODBC Driver 18 for SQL Server, aktualnej serii sterowników. Microsoft ODBC Driver 17 dla SQL Server pozostaje wspierany dla aplikacji, które już go wdrażają, zgodnie z opisem cyklu wsparcia.

Zmiana w aktualizacji, która dotyczy większości aplikacji, polega na tym, że sterownik 18 domyślnie szyfruje połączenia. Wszystkie różnice znajdziesz w sekcji Różnice między głównymi wersjami.

Sterownik 18 obsługuje następujące systemy operacyjne i architektury procesorów:

Wersje obsługiwanych systemów operacyjnych zmieniają się z każdym wydaniem sterownika. Tabelę według wersji można znaleźć w artykule Wymagania systemowe.

Sterownik na Linuksie i macOS obsługuje większość funkcji SQL Server. Nie obsługuje rozproszonego rejestrowania transakcji poprzez atrybut SQL_ATTR_ENLIST_IN_DTC, mirroring bazy danych, FILESTREAM ani atrybuty profilowania wydajności sterowników. LocalDB nie jest dostępny w systemie Linux ani macOS. Transakcje XA za pośrednictwem Koordynatora Transakcji Rozproszonych (DTC) są obsługiwane począwszy od wersji sterownika 17.3. Więcej informacji można znaleźć w artykule Używaj transakcji XA z DTC. Pełną listę można znaleźć w artykule Ograniczenia.

No. Sterownik Microsoft ODBC dla SQL Server nie jest open source.

Sterownik korzysta z menedżera sterowników unixODBC. Gdy instalujesz sterownik 17 lub 18 za pomocą menedżera pakietów platformy lub Homebrew, unixODBC instaluje się jako zależność. Postępuj zgodnie z instrukcjami dla Linuksa lub macOS.

Na macOS buduj i uruchamiaj aplikację w unixODBC zamiast iODBC. Dopasuj architekturę aplikacji, menedżera sterowników i sterownika. Błąd taki incompatible architecture (have 'arm64', need 'x86_64') wskazuje na niedopasowanie architektury, a niekoniecznie na niewłaściwy menedżer sterowników.

Uruchom odbcinst -q -d, aby wyświetlić zarejestrowane sterowniki. Wyjście pokazuje nazwę każdego sterownika dokładnie tak, jak musi być zapisana w parametry połączeniau:

[ODBC Driver 18 for SQL Server]

Uruchom odbcinst -j , aby pokazać wersję unixODBC oraz ścieżki odbcinst.ini, która rejestruje sterowniki, oraz odbc.ini, która przechowuje nazwy źródeł danych systemowych i użytkownika (DSN):

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

Aby skonfigurować DSN, zobacz Parametry połączenia i DSN.

Błąd wygląda tak:

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

Sprawdź te przyczyny w kolejności:

1. Wartość Driver w parametry połączenia lub DSN nie odpowiada zarejestrowanej nazwie sterownika. Uruchom odbcinst -q -d i skopiuj nazwę bez zmian.
2. Twoja aplikacja używa innych plików konfiguracyjnych niż te, które edytowałeś. Uruchom odbcinst -j z tego samego środowiska co aplikacja i sprawdź, który menedżer sterowników aplikacja ładuje. Na macOS twórz symboliczne linki konfiguracyjne tylko wtedy, gdy aplikacja ich wymaga, jak opisano w sekcji Troubleshooting on macOS.
3. Zainstalowano więcej niż jedną kopię menedżera sterowników unixODBC, a Twoja aplikacja ładuje niewłaściwy menedżer sterowników. W systemie Linux uruchom polecenie find /usr -name 'libodbc*.so*'. Na macOS uruchom find /opt/homebrew /usr/local -name 'libodbc*.dylib'. Sam fakt istnienia wielu ścieżek nie dowodzi, że zainstalowanych jest wiele menedżerów sterowników: linki Homebrew mogą wskazywać na tę samą bibliotekę w katalogu Cellar. Sprawdź, którą bibliotekę faktycznie ładuje aplikacja. Więcej informacji można znaleźć w artykule Rozwiązywanie problemów z połączeniem.

Sterownik 18 ma domyślnie ustawione Encrypt=yes. Sterownik 17 domyślnie używa wartości Encrypt=no tylko wtedy, gdy nie jest dostarczone żadne niepuste Authentication ustawienie lub token dostępu. Niepuste ustawienie, w tym Authentication i Authentication=SqlPassword, lub token dostępu zmienia wartość domyślną w Driver 17 na Encrypt=yes. Jawne ustawienia szyfrowania nadpisują te domyślne ustawienia.

Sprawdź efektywne ustawienia w swoim parametry połączenia, DSN oraz atrybutach preconnection ustawionych przez SQLSetConnectAttr. Na przykład, SQL_COPT_SS_ENCRYPT=SQL_EN_ON w nazwie DSN lub Encrypt=yes wymaga szyfrowania nawet wtedy, gdy parametry połączenia pomijają Encrypt. Dostarczaj tokeny dostępu tylko za pomocą atrybutu połączenia SQL_COPT_SS_ACCESS_TOKEN, a nie słowa kluczowego parametrów połączenia.

Z Encrypt=yes i TrustServerCertificate=no, oba sterowniki szyfrują połączenie i weryfikują certyfikat serwera. Przy Encrypt=no, sterownik 17 nie waliduje certyfikatu, natomiast sterownik 18 go waliduje, jeśli serwer wymusza szyfrowanie i TrustServerCertificate=no. Połączenie, które wcześniej korzystało z domyślnego ustawienia Sterownika 17 Encrypt=no, może więc zakończyć się niepowodzeniem przy użyciu Sterownika 18 podczas połączenia z serwerem z certyfikatem podpisanym samodzielnie lub w inny sposób niezaufanym. W przypadku certyfikatu podpisanego samodzielnie błąd sterownika 18 wygląda tak:

[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

Preferuj zaufany certyfikat lub przypinanie certyfikatów. Skorzystaj z następujących opcji:

• Zainstaluj certyfikat na serwerze wydany przez urząd certyfikacji, któremu klient ufa. Jeśli certyfikat jest zaufany, ale jego nazwa nie zgadza się z wartością Server, ustaw HostNameInCertificate na nazwę z certyfikatu. HostNameInCertificate Zmienia tylko oczekiwaną nazwę, więc nie naprawia certyfikatu samopodpisanego.
• W przypadku sterownika Driver 18.1 i nowszych wersji oraz serwera obsługującego Tabular Data Stream (TDS) 8.0 ustaw Encrypt=strict i ustaw ServerCertificate na ścieżkę do kopii certyfikatu serwera. Sterownik akceptuje wtedy tylko dokładnie ten certyfikat. ServerCertificate To działa tylko w trybie ścisłym.
• Ustaw Encrypt=no tylko, jeśli akceptujesz nieszyfrowany ruch aplikacji, gdy serwer nie wymusza szyfrowania. Jest to zgodne z domyślnym Sterownikiem 17 tylko wtedy, gdy nie jest podane żadne niepuste ustawienie Authentication ani token dostępu i nie jest ustawione żadne nadpisanie ustawienia szyfrowania. Jeśli serwer wymusi szyfrowanie, sterownik 18 nadal sprawdza poprawność certyfikatu, chyba że ustawienie TrustServerCertificate=yes wyłącza tę weryfikację.

Więcej informacji można znaleźć w artykule Domyślne zachowanie szyfrowania.

Tak. Uzyskaj bilet Kerberos za pomocą kinit, a następnie połącz się za pomocą Trusted_Connection=yes w parametrach połączenia lub DSN. Instancja SQL Server wymaga zarejestrowanej nazwy głównej usługi (SPN). Szczegóły dotyczące konfiguracji znajdziesz w artykule Używanie uwierzytelniania zintegrowanego.

Tak, dla Azure SQL Database, Azure SQL Managed Instance oraz SQL Server 2022 i nowszych. Aby skonfigurować SQL Server, w tym przez Azure Arc, użyj uwierzytelniania Microsoft Entra dla programu SQL Server. Na Linuksie i macOS wersje Driver 17 i nowsze obsługują następujące metody:

• Tożsamość zarządzana, z Authentication=ActiveDirectoryMsi, dostępna od wersji Driver 17.3.
• Jednostka usługi, z Authentication=ActiveDirectoryServicePrincipal, zaczynając od sterownika 17.7.
• Zintegrowane uwierzytelnianie przez Kerberos w środowisku federacyjnym, za pomocą Authentication=ActiveDirectoryIntegrated, zaczynając od sterownika 17.6.
• Token dostępu, który Twoja aplikacja otrzymuje, przekazywany za pomocą atrybutu połączenia SQL_COPT_SS_ACCESS_TOKEN.

ActiveDirectoryInteractivejest dostępny tylko w sterowniku Windows. ActiveDirectoryPassword jest wycofane z użycia. Uwierzytelnianie zarządzane sterownikami na Linuksie i macOS nie obsługuje scenariuszy wymagających polityk dostępu warunkowego. Jeśli Twoja aplikacja pozyskuje token dostępu osobno, to biblioteka uwierzytelniania oraz polityki Microsoft Entra ID regulują to pozyskanie tokenu. Przekaż token przez SQL_COPT_SS_ACCESS_TOKEN.

W Alpine Linux zintegrowana autyzacja wymaga kompilacji libcurl z obsługą mechanizmu Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO). Sprawdź swoje zainstalowane libcurl funkcje, zamiast zakładać, że domyślny pakiet to obsługuje.

Aby uzyskać łańcuchy połączeń i przykłady kodu, zobacz Użyj Microsoft Entra ID z sterownikiem ODBC.

Tak. Aplikacja napisana zgodnie z interfejsem programowania aplikacji ODBC (API) i zbudowana z użyciem unixODBC może załadować ten sterownik. Aby korzystać z funkcji specyficznych dla SQL Server, należy dołączyć msodbcsql.h po nagłówkach unixODBC. Aby uzyskać polecenia kompilatora i nazwy bibliotek, zobacz Develop C and C++ applications with the ODBC driver.

Tak. Nawiązywanie połączenia i wykonywanie zapytań przy użyciu C++ i ODBC opisuje kompilowanie i uruchamianie przykładu w systemach Linux, macOS i Windows.

Pliki śledzenia mogą zawierać wrażliwe dane. Jako konto, które uruchamia Twoją aplikację, stwórz katalog, do którego dostęp ma tylko to konto:

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

Dodaj te ustawienia do sekcji [ODBC] w odbcinst.ini. Zamień /home/<user>/odbc-trace/odbctrace.log na ścieżkę absolutną w katalogu, który utworzyłeś. Na macOS katalogi domowe zazwyczaj używają /Users/<user> zamiast /home/<user>.

Zachowaj pełną ścieżkę pliku śledzenia do 62 bajtów lub mniej, aby uniknąć obcięcia przez unixODBC.

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

Te ustawienia umożliwiają włączenie śledzenia dla aplikacji korzystających z tej konfiguracji menedżera sterowników, a śledzenie je spowalnia. Używaj osobnego prywatnego katalogu dla każdego konta aplikacji. Usuń Trace = Yes po zakończeniu i usuń pliki śledzenia, których już nie potrzebujesz. Informacje o śledzeniu dla poszczególnych aplikacji znajdziesz w artykule Data access tracing on Linux and macOS.

Użyj UTF-16LE (little endian) dla danych SQLWCHAR. Używaj buforów UTF-16 SQLWCHAR z API ODBC o szerokich znakach zamiast natywnego wchar_t typu, który jest 32-bitowy na Linuksie i macOS.

Używaj kodowania UTF-8 dla danych SQLCHAR. Począwszy od sterownika 17, sterownik akceptuje także zestaw jednobajtowych i dwubajtowych stron kodowych dla danych SQLCHAR, gdy ustawienia regionalne procesu wybiorą jedną z nich. Procesy zaczynają się w ustawieniach regionalnych C, więc sterownik używa UTF-8, chyba że aplikacja wywoła setlocale. Listę kodowań można znaleźć w sekcji Obsługa danych znaków.