Condividi tramite

Linee guida per la programmazione

  • Articolo

Scaricare il driver ODBC

Le funzionalità di programmazione di Microsoft ODBC Driver for SQL Server in macOS e Linux si basano su ODBC in SQL Server Native Client (ODBC) (SQL Server Native Client (ODBC)). SQL Server Native Client si basa su ODBC in Windows Data Access Components (Informazioni di riferimento per programmatori di ODBC).

Un'applicazione ODBC può usare MARS (Multiple Active Result Set) e altre funzionalità specifiche di SQL Server includendo /usr/local/include/msodbcsql.h dopo le intestazioni unixODBC (sql.h, sqlext.h, sqltypes.h e sqlucode.h). Per elementi specifici di SQL Server, si usano quindi gli stessi nomi simbolici che si userebbero nelle applicazioni ODBC di Windows.

Funzionalità disponibili

Quando si usa il driver ODBC in macOS o Linux, sono valide le sezioni seguenti della documentazione di SQL Server Native Client for ODBC (SQL Server Native Client (ODBC)):

Caratteristiche non supportate

Il corretto funzionamento delle funzionalità seguenti non è stato verificato in questa versione del driver ODBC in macOS e Linux:

Le funzionalità seguenti non sono disponibili nel driver ODBC in macOS e Linux:

  • Transazioni distribuite (l'attributo SQL_ATTR_ENLIST_IN_DTC non è supportato)
  • Mirroring del database
  • FILESTREAM
  • Profilatura delle prestazioni del driver ODBC, descritta in SQLSetConnectAttr e gli attributi di connessione correlati alle prestazioni seguenti:
    • 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 (prima della versione 17.2)
  • I tipi di intervallo C, ad esempio SQL_C_INTERVAL_YEAR_TO_MONTH (documentati nell'articolo relativo a identificatori e descrittori del tipo di dati) non sono attualmente supportati
  • Valore SQL_CUR_USE_ODBC dell'attributo SQL_ATTR_ODBC_CURSORS della funzione SQLSetConnectAttr.

Supporto del set di caratteri

Per ODBC Driver 13 e 13.1 i dati SQLCHAR devono essere in formato UTF-8. Non sono supportate altre codifiche.

Per ODBC Driver 17 sono supportati i dati SQLCHAR in uno dei seguenti set/codifiche di caratteri:

Nota

A causa delle differenze di iconv in musl e glibc, molte di queste impostazioni locali non sono supportate in Alpine Linux.

Per altre informazioni, vedere Functional differences from glibc (Differenze funzionali da glibc)

Nome Descrizione
UTF-8 Unicode
CP437 MS-DOS Latino US
CP850 MS-DOS Latino 1
CP874 Latino/Thai
CP932 Giapponese (Shift-JIS)
CP936 Cinese semplificato (GBK)
CP949 Coreano EUC-KR
CP950 Cinese tradizionale (Big5)
CP1251 Cirillico
CP1253 Greco
CP1256 arabo
CP1257 Baltico
CP1258 Vietnamita
ISO-8859-1/CP1252 Latino-1
ISO-8859-2/CP1250 Latino-2
ISO-8859-3 Latino-3
ISO-8859-4 Latino-4
ISO-8859-5 Latino/Cirillico
ISO-8859-6 Latino/Arabo
ISO-8859-7 Latino/Greco
ISO-8859-8/CP1255 Ebraico
ISO-8859-9/CP1254 Turco
ISO-8859-13 Latino-7
ISO-8859-15 Latino-9

Al momento della connessione il driver rileva le impostazioni locali correnti del processo nel quale viene caricato. Se il processo usa una delle codifiche precedenti, il driver usa quella codifica per i dati SQLCHAR (caratteri narrow); in caso contrario assume come impostazione predefinita UTF-8. Dato che tutti i processi iniziano con le impostazioni locali "C" per impostazione predefinita (e di conseguenza il driver assume come impostazione predefinita UTF-8), se un'applicazione deve usare una delle codifiche sopra elencate, dovrà usare la funzione setlocale per definire correttamente le impostazioni locali, sia specificando in modo esplicito le impostazioni desiderate, sia usando una stringa vuota come setlocale(LC_ALL, "") per richiedere l'uso delle impostazioni locali dell'ambiente.

Pertanto, in un tipico ambiente Linux o macOS in cui la codifica è UTF-8, gli utenti di del driver ODBC 17 che eseguono l'aggiornamento dalla versione 13 o 13.1 non noteranno alcuna differenza. Tuttavia le applicazioni che usano una codifica non UTF-8 inclusa nell'elenco precedente tramite setlocale() dovranno usare tale codifica per i dati da e verso il driver, anziché usare UTF-8.

I dati SQLWCHAR devono essere in formato UTF-16LE (Little Endian).

Se quando si esegue il binding di parametri di input con SQLBindParameter è specificato un tipo di carattere SQL narrow come SQL_VARCHAR, il driver converte i dati trasmessi dalla codifica dell'utente alla codifica predefinita di SQL Server (in genere la tabella codici 1252). Per i parametri di output il driver esegue la conversione dalla codifica specificata nelle informazioni delle regole di confronto associate ai dati alla codifica del client. Può tuttavia verificarsi la perdita di dati: i caratteri nella codifica di origine non rappresentabili nella codifica di destinazione verranno convertiti in punti interrogativi (?).

Per evitare questo tipo di perdita di dati nel binding dei parametri di input, specificare un tipo di carattere SQL Unicode, ad esempio SQL_NVARCHAR. In questo caso il driver esegue la conversione dalla codifica del client a UTF-16, che può rappresentare tutti i caratteri Unicode. Anche la colonna o il parametro di destinazione nel server deve essere di tipo Unicode (nchar, nvarchar, ntext) o avere regole di confronto/codifica che possono rappresentare tutti i caratteri dei dati di origine. Per evitare la perdita di dati con i parametri di output, specificare un tipo Unicode SQL e un tipo Unicode C (SQL_C_WCHAR) (per far sì che il driver restituisca i dati in formato UTF-16) o un tipo C narrow e verificare che la codifica client sia in grado di rappresentare tutti i caratteri dei dati di origine (questa rappresentazione è sempre possibile con UTF-8).

Per altre informazioni sulle regole di confronto e sulle codifiche, vedere Regole di confronto e supporto Unicode.

Esistono alcune differenze di conversione della codifica tra Windows e varie versioni della libreria iconv in Linux e macOS. Nei dati di testo codificati nella tabella codici 1255 (Ebraico) un punto di codice (0xCA) si comporta in modo diverso in caso di conversione a Unicode. In Windows questo carattere viene convertito nel punto di codice UTF-16 0x05BA. In macOS e Linux con versioni di libiconv precedenti alla 1.15 viene convertito in 0x00CA. In Linux con le librerie iconv che non supportano la revisione 2003 di Big5/CP950 (denominata BIG5-2003) i caratteri aggiunti con questa revisione non vengono convertiti correttamente. Anche nella tabella codici 932 (Giapponese, Shift-JIS) il risultato della decodifica dei caratteri non definiti in origine nello standard di codifica è diverso. Ad esempio il byte 0x80 viene convertito in U+0080 in Windows ma può diventare U+30FB in Linux e macOS, a seconda della versione di iconv.

In ODBC Driver 13 e 13.1, quando caratteri multibyte UTF-8 o caratteri sostitutivi UTF-16 vengono suddivisi tra buffer SQLPutData, i dati vengono danneggiati. Usare i buffer per i flussi SQLPutData che non terminano con la codifica parziale di caratteri. Questa restrizione è stata eliminata con ODBC Driver 17.

OpenSSL

A partire dalla versione 17.4, il driver carica OpenSSL in modo dinamico, consentendone l'esecuzione all'interno di sistemi dotati della versione 1.0 o 1.1 senza che siano necessari file di driver distinti. A partire dalla versione 17.9, il driver supporta OpenSSL 3.0 oltre alle versioni precedenti. Quando sono presenti più versioni di OpenSSL, il driver tenta di caricare quello più recente.

Versione driver Versioni di OpenSSL supportate
17.4+ 1.0, 1.1
17.9, 18.0+ 1.0, 1.1, 3.0

Nota

Può verificarsi un conflitto se l'applicazione che usa il driver (o uno dei suoi componenti) è collegata a una versione diversa di OpenSSL o la carica in modo dinamico. Se nel sistema sono presenti diverse versioni di OpenSSL e l'applicazione usa OpenSSL, è consigliabile prestare particolare attenzione affinché la versione caricata dall'applicazione e il driver corrispondano. In caso contrario, infatti, gli errori possono danneggiare la memoria e non presentarsi necessariamente in modo ovvio o coerente.

Alpine Linux

Al momento della stesura di questo articolo, la dimensione predefinita dello stack in MUSL è 128 KB, sufficiente per le funzionalità di base del driver ODBC. A seconda delle operazioni svolte dall'applicazione, tuttavia, non è difficile superare questo limite, soprattutto quando si chiama il driver da più thread. È consigliabile compilare un'applicazione ODBC in Alpine Linux con -Wl,-z,stack-size=<VALUE IN BYTES> per aumentare la dimensione dello stack. Per riferimento, la dimensione predefinita dello stack nella maggior parte dei sistemi GLIBC è di 2 MB.

Note aggiuntive

  • È possibile effettuare una connessione amministrativa dedicata (DAC) usando l'autenticazione di SQL Server e host, porta. Un membro del ruolo Sysadmin deve prima individuare la porta DAC. Per altre informazioni, vedere Connessione di diagnostica per gli amministratori di database. Ad esempio, se la porta DAC è 33000, è possibile connettersi a questa porta con sqlcmd come indicato di seguito:

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

    Nota

    Le connessioni DAC devono usare l'autenticazione di SQL Server.

  • Gestione driver UnixODBC restituisce "Identificatore di opzione o di attributo non valido" per tutti gli attributi di istruzione quando questi vengono passati tramite SQLSetConnectAttr. In Windows, quando SQLSetConnectAttr riceve il valore di un attributo di istruzione, il driver imposta questo valore in tutte le istruzioni attive figlio dell'handle di connessione.

  • Quando si usa il driver con applicazioni a elevato multithreading, la convalida degli handle di unixODBC può diventare un collo di bottiglia per le prestazioni. In questi scenari è possibile ottenere prestazioni più elevate compilando unixODBC con l'opzione --enable-fastvalidate. Tenere presente, tuttavia, che con questa opzione le applicazioni che passano handle non validi alle API ODBC possono subire un arresto anomalo anziché restituire errori SQL_INVALID_HANDLE.

Vedi anche

Domande frequenti
Problemi noti in questa versione del driver
Note sulla versione