Domande frequenti per ODBC su Linux e macOS

Usa il driver ODBC 18 di Microsoft per SQL Server, l'attuale linea di driver, per nuovi sviluppi. Il driver ODBC 17 di Microsoft per SQL Server rimane supportato per applicazioni che già lo distribuiscono, come descritto nel ciclo di vita del supporto.

La modifica introdotta con l'aggiornamento che riguarda la maggior parte delle applicazioni è che il Driver 18 cripta le connessioni per impostazione predefinita. Per tutte le differenze, vedi Differenze delle versioni principali.

Il driver 18 supporta questi sistemi operativi e architetture di processore:

Le versioni del sistema operativo supportate cambiano ad ogni rilascio del driver. Per la tabella suddivisa per versione, consulta Requisiti di sistema.

Il driver su Linux e macOS supporta la maggior parte delle funzionalità di SQL Server. Non supporta l'arruolamento nelle transazioni distribuite tramite l'attributo SQL_ATTR_ENLIST_IN_DTC, il mirroring del database, il FILESTREAM o gli attributi di profilazione delle prestazioni del driver. LocalDB non è disponibile su Linux o macOS. Le transazioni XA tramite il Distributed Transaction Coordinator (DTC) sono supportate a partire dal Driver 17.3. Per maggiori informazioni, vedi Usare le transazioni XA con DTC. Per l'elenco completo, vedi Limitazioni.

No. Il driver Microsoft ODBC per SQL Server non è open source.

Il driver utilizza il gestore driver unixODBC. Quando installi il driver 17 o 18 con il package manager o Homebrew della tua piattaforma, unixODBC si installa come dipendenza. Segui i passaggi per Linux o macOS.

Su macOS, compila ed esegui la tua applicazione con unixODBC invece che con iODBC. Abbina l'architettura del processore dell'applicazione, del driver manager e del driver. Un errore come incompatible architecture (have 'arm64', need 'x86_64') indica una discrepanza di architettura, non necessariamente il driver manager sbagliato.

Esegui odbcinst -q -d per elencare i driver registrati. L'output mostra il nome di ogni driver esattamente come deve essere scritto da una stringa di connessione:

[ODBC Driver 18 for SQL Server]

Esegui odbcinst -j per mostrare la versione unixODBC e i percorsi di odbcinst.ini, che registra i driver, e odbc.ini, che contiene i nomi delle sorgenti dati di sistema e utente (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

Per configurare una DSN, vedi Stringhe di connessione e DSN.

L'errore è simile a questo:

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

Controlla queste cause in ordine:

1. Il Driver valore nella stringa di connessione o nel DSN non corrisponde a un nome driver registrato. Esegui odbcinst -q -d e copia il nome esattamente.
2. La tua applicazione utilizza file di configurazione diversi da quelli che hai modificato. Esegui odbcinst -j dallo stesso ambiente dell'applicazione e controlla quale driver manager carica l'applicazione. Su macOS, crea link simbolici di configurazione solo se l'applicazione ne ha bisogno, come descritto in Troubleshooting su macOS.
3. Più di una copia del driver manager unixODBC è installata, e la tua applicazione carica quella sbagliata. In Linux eseguire find /usr -name 'libodbc*.so*'. Su macOS, esegui find /opt/homebrew /usr/local -name 'libodbc*.dylib'. Più percorsi da soli non dimostrano che siano installati più driver manager: i link homebrew possono puntare alla stessa libreria nella sua directory Cellar. Controlla quale libreria l'applicazione carica effettivamente. Per maggiori informazioni, vedi Risoluzione problemi di connessione.

Il driver 18 usa Encrypt=yes come predefinito. Il driver 17 usa Encrypt=no per impostazione predefinita solo quando non viene fornita alcuna impostazione Authentication non vuota o token di accesso. Un'impostazione non vuota Authentication , inclusa Authentication=SqlPassword, o un token di accesso, cambia il Driver 17 di default in Encrypt=yes. Le impostazioni di crittografia esplicite sovrascrivono queste impostazioni predefinite.

Controlla le impostazioni effettive nella tua stringa di connessione, DSN e attributi preconnection impostati tramite SQLSetConnectAttr. Ad esempio, Encrypt=yes in una DSN o SQL_COPT_SS_ENCRYPT=SQL_EN_ON richiedono la crittografia anche quando la stringa di connessione omette Encrypt. Fornire token di accesso solo tramite l'attributo di connessione SQL_COPT_SS_ACCESS_TOKEN, non tramite una parola chiave della stringa di connessione.

Con TrustServerCertificate=no e Encrypt=yes, entrambi i driver criptano la connessione e validano il certificato del server. Con Encrypt=no, il driver 17 non valida il certificato, mentre il driver 18 lo valida se il server forza la crittografia e TrustServerCertificate=no. Una connessione che in precedenza utilizzava il default del Driver 17 Encrypt=no può quindi fallire con il Driver 18 contro un server con un certificato autofirmato o comunque non affidabile. Con un certificato autofirmato, l'errore del Driver 18 appare così:

[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

Preferisci un certificato affidabile o il certificate pinning. Usa queste opzioni:

• Installa un certificato sul server emesso da un'autorità certificatrice di cui il client si fida. Se il certificato è affidabile ma il suo nome non corrisponde al valore Server, imposta HostNameInCertificate sul nome nel certificato. HostNameInCertificate Cambia solo il nome atteso, quindi non corregge un certificato autofirmato.
• Con il Driver 18.1 e versioni successive e un server che supporta Tabular Data Stream (TDS) 8.0, imposta Encrypt=strict e imposta ServerCertificate al percorso di una copia del certificato del server. Il conducente accetta quindi solo proprio quel certificato. ServerCertificate funziona solo in modalità rigorosa.
• Imposta Encrypt=no solo se accetti traffico applicativo non criptato quando il server non forza la crittografia. Questo corrisponde al valore predefinito del Driver 17 solo quando non viene fornita alcuna impostazione non vuota Authentication o token di accesso e non viene impostato alcun override di crittografia. Se il server forza la crittografia, il Driver 18 valida comunque il certificato a meno che TrustServerCertificate=yes non disabiliti la validazione.

Per maggiori informazioni, vedi Comportamento di crittografia predefinito.

Sì. Ottieni un ticket Kerberos con kinit, poi connettiti con Trusted_Connection=yes nella stringa di connessione o nel DSN. L'istanza di SQL Server necessita di un Service Principal Name (SPN) registrato. Per i passaggi di configurazione, vedi Usare l'autenticazione integrata.

Sì, per database SQL di Azure, Istanza gestita di SQL di Azure e SQL Server 2022 e versioni successive. Per configurare SQL Server, anche tramite Azure Arc, usa l'autenticazione Microsoft Entra per SQL Server. Su Linux e macOS, il Driver 17 e le versioni successive supportano questi metodi:

• Identità gestita, con Authentication=ActiveDirectoryMsi, a partire dal Driver 17.3.
• Service principal, con Authentication=ActiveDirectoryServicePrincipal, a partire dal Driver 17.7.
• Autenticazione integrata tramite Kerberos in un ambiente federato, con Authentication=ActiveDirectoryIntegrated, a partire dal Driver 17.6.
• Un token di accesso ottenuto dall'applicazione, passato tramite l'attributo di connessione SQL_COPT_SS_ACCESS_TOKEN.

ActiveDirectoryInteractiveè disponibile solo nel driver Windows. ActiveDirectoryPassword è deprecato. L'autenticazione gestita dai driver su Linux e macOS non supporta scenari che richiedono policy di accesso condizionato. Se la tua applicazione acquisisce un token di accesso separatamente, la libreria di autenticazione e le policy di Microsoft Entra ID disciplinano l'acquisizione del token. Passa il token attraverso SQL_COPT_SS_ACCESS_TOKEN.

Su Alpine Linux, l'autenticazione integrata richiede una libcurl build con supporto per il Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO). Controlla le capacità installate libcurl invece di presumere che il pacchetto predefinito le supporti.

Per stringhe di connessione e esempi di codice, vedi Usa Microsoft Entra ID con il driver ODBC.

Sì. Un'applicazione scritta sull'interfaccia di programmazione applicativa ODBC (API) e costruita su unixODBC può caricare questo driver. Per utilizzare funzionalità specifiche di SQL Server, includere msodbcsql.h dopo le intestazioni unixODBC. Per comandi compilatori e nomi di librerie, vedi Sviluppa applicazioni C e C++ con il driver ODBC.

Sì. Connettersi ed eseguire query con C++ e ODBC compila ed esegue un esempio su Linux, macOS e Windows.

I file di traccia possono contenere dati sensibili. Con l'account che esegue la tua applicazione, crea una directory a cui solo quell'account può accedere:

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

Aggiungi queste impostazioni alla sezione [ODBC] di odbcinst.ini. Sostituisci /home/<user>/odbc-trace/odbctrace.log con il percorso assoluto all'interno della directory che hai creato. Su macOS, le directory home tipicamente usano /Users/<user> invece di /home/<user>.

Mantieni il percorso completo del file di traccia a 62 byte o meno per evitare la troncatura da parte di unixODBC.

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

Queste impostazioni consentono il tracciamento per applicazioni che utilizzano questa configurazione di driver manager, e il tracciamento le rallenta. Usa una directory privata separata per ogni account applicativo. Rimuovi Trace = Yes quando hai finito e elimina i file di traccia che non ti servono più. Per il tracciamento per applicazione, vedi tracciamento degli accessi dati su Linux e macOS.

Usa UTF-16LE (little endian) per i SQLWCHAR dati. Usa buffer UTF-16 SQLWCHAR con le API ODBC a caratteri ampi invece del tipo nativo wchar_t , che è a 32 bit su Linux e macOS.

Usa UTF-8 per SQLCHAR dati. A partire dal Driver 17, il driver accetta anche un insieme di code page a singolo e doppio byte per i dati SQLCHAR quando le impostazioni locali del processo ne selezionano una. I processi iniziano nel C locale, quindi il driver usa UTF-8 a meno che l'applicazione non chiami setlocale. Per l'elenco delle codifiche, vedi Gestire i dati dei caratteri.