Instructions de programmation

  • Article

Télécharger le pilote ODBC

Les fonctionnalités de programmation de Microsoft ODBC Driver for SQL Server sur macOS et Linux reposent sur ODBC dans SQL Server Native Client (SQL Server Native Client (ODBC)). SQL Server Native Client se base sur ODBC dans Windows Data Access Components (Guide de référence du programmeur ODBC).

Une application ODBC peut utiliser MARS (Multiple Active Result Sets) et d’autres fonctionnalités spécifiques SQL Server en incluant /usr/local/include/msodbcsql.h après avoir inclus les en-têtes unixODBC (sql.h, sqlext.h, sqltypes.h et sqlucode.h). Utilisez alors les mêmes noms symboliques pour les éléments spécifiques à SQL Server que dans vos applications ODBC Windows.

Fonctionnalités disponibles

Les sections suivantes de la documentation de SQL Server Native Client pour ODBC (SQL Server Native Client (ODBC)) sont valides quand vous utilisez le pilote ODBC sur macOS et Linux :

Fonctions non prises en charge

Le bon fonctionnement des fonctionnalités suivantes n’a pas été vérifié dans le pilote ODBC sur macOS et Linux :

Les fonctionnalités suivantes ne sont pas disponibles dans le pilote ODBC sur macOS et Linux :

  • Transactions distribuées (attribut SQL_ATTR_ENLIST_IN_DTC non pris en charge)
  • Mise en miroir de bases de données
  • FILESTREAM
  • Profilage des performances du pilote ODBC, décrit dans SQLSetConnectAttr et attributs de connexion liés aux performances suivants :
    • 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 (avant la version 17.2)
  • Types d’intervalle C comme SQL_C_INTERVAL_YEAR_TO_MONTH (décrits dans Identificateurs et descripteurs des types de données)
  • Valeur SQL_CUR_USE_ODBC de l’attribut SQL_ATTR_ODBC_CURSORS de la fonction SQLSetConnectAttr.

Prise en charge du jeu de caractères

Pour ODBC Driver 13 et 13.1, les données SQLCHAR doivent être au format UTF-8. Aucun autre encodage n’est pris en charge.

Pour ODBC Driver 17, les données SQLCHAR dans un des jeux de caractères/encodages suivants sont prises en charge :

Notes

En raison des différences de iconv dans musl et glibc, beaucoup de ces paramètres régionaux ne sont pas pris en charge sur Alpine Linux.

Pour plus d’informations, consultez Différences fonctionnelles par rapport à glibc

Nom Description
UTF-8 Unicode
CP437 MS-DOS Latin US
CP850 MS-DOS Latin 1
CP874 Latin/thaï
CP932 Japonais, Shift-JIS
CP936 Chinois simplifié, GBK
CP949 Coréen, EUC-KR
CP950 Chinois traditionnel, Big5
CP1251 Cyrillique
CP1253 Grec
CP1256 Arabe
CP1257 Balte
CP1258 Vietnamien
ISO-8859-1 / CP1252 Latin-1
ISO-8859-2 / CP1250 Latin-2
ISO-8859-3 Latin-3
ISO-8859-4 Latin-4
ISO-8859-5 Latin/cyrillique
ISO-8859-6 Latin/arabe
ISO-8859-7 Latin/grec
ISO-8859-8 / CP1255 Hébreu
ISO-8859-9 / CP1254 Turc
ISO-8859-13 Latin-7
ISO-8859-15 Latin-9

Au moment de la connexion, le pilote détecte les paramètres régionaux actuels du processus dans lequel il est chargé. S’il utilise un des encodages ci-dessus, le pilote s’en sert pour les données SQLCHAR (caractères étroits) ; sinon, il utilise par défaut l’encodage UTF-8. Dans la mesure où tous les processus démarrent par défaut dans les paramètres régionaux « C » (ce qui amène le pilote à utiliser par défaut le format UTF-8), une application qui doit utiliser l’un des encodages ci-dessus aura recours à la fonction setlocale pour définir les bons paramètres régionaux avant la connexion. Deux possibilités existent : spécifier explicitement les paramètres régionaux ou utiliser une chaîne vide (par exemple setlocale(LC_ALL, "")) pour exploiter les paramètres régionaux de l’environnement.

Ainsi, dans un environnement Linux ou macOS standard où l’encodage est UTF-8, les utilisateurs qui passent de la version 13 ou 13.1 à la version 17 d’ODBC Driver ne constatent aucune différence. Toutefois, les applications qui utilisent un codage non-UTF-8 dans la liste ci-dessus par le biais de setlocale() doivent recourir à cet encodage pour les données vers et depuis le pilote au lieu d’UTF-8.

Les données SQLWCHAR doivent être au format UTF-16LE (Little Endian).

Au moment de la liaison des paramètres d’entrée avec SQLBindParameter, si un type SQL à caractères étroits tel que SQL_VARCHAR est spécifié, le pilote convertit les données fournies depuis l’encodage client vers l’encodage SQL Server par défaut (en général, la page de codes 1252). Pour les paramètres de sortie, le pilote effectue une conversion depuis l’encodage spécifié dans les informations de classement associées aux données vers l’encodage client. Toutefois, une perte de données est possible : les caractères dans l’encodage source qui ne sont pas représentables dans l’encodage cible sont convertis en point d’interrogation (« ? »).

Pour éviter cette perte de données au moment de la liaison des paramètres d’entrée, spécifiez un type de caractère SQL Unicode, comme SQL_NVARCHAR. Dans ce cas, le pilote effectue une conversion depuis l’encodage client vers le format UTF-16, qui peut représenter tous les caractères Unicode. En outre, la colonne ou paramètre cible sur le serveur doit également être un type Unicode (nchar, nvarchar, ntext) ou doté d’un classement/encodage pouvant représenter tous les caractères des données sources d’origine. Pour éviter toute perte de données avec les paramètres de sortie, spécifiez un type SQL Unicode et soit un type C Unicode (SQL_C_WCHAR), afin que le pilote retourne les données au format UTF-16, soit un type C à caractères étroits. Veillez également à ce que l’encodage client puisse représenter tous les caractères des données sources (cette représentation est toujours possible avec le format UTF-8).

Pour plus d’informations sur les classements et les codages, voir Prise en charge d’Unicode et des classements.

Il existe certaines différences de conversion d’encodage entre Windows et plusieurs versions de la bibliothèque iconv sur Linux et macOS. Les données texte dans la page de codes 1255 (hébreu) ont un seul point de code (0xCA) qui se comporte différemment au moment de la conversion en Unicode. Sur Windows, ce caractère est converti dans le point de code UTF-16 0x05BA. Sur macOS et Linux avec versions de libiconv antérieures à 1.15, il est converti dans le point de code 0x00CA. Sur Linux avec les bibliothèques iconv qui ne prennent pas en charge la révision 2003 de Big5/CP950 (nommée BIG5-2003), les caractères ajoutés à cette révision ne sont pas convertis correctement. Dans la page de codes 932 (japonais, Shift-JIS), le résultat du décodage de caractères qui ne sont pas initialement définis dans le standard d’encodage est également différent. Par exemple, l’octet 0x80 est converti en U+0080 sur Windows, mais peut devenir U+30FB sur Linux et macOS, suivant la version d’iconv.

Dans ODBC Driver 13 et 13.1, quand des caractères multioctets UTF-8 ou des substituts UTF-16 sont répartis entre les mémoires tampons SQLPutData, les données sont altérées. Utilisez des mémoires tampons pour diffuser en continu les données SQLPutData qui ne se terminent pas dans des encodages de caractères partiels. Cette restriction a été supprimée avec ODBC Driver 17.

OpenSSL

À partir de la version 17.4, le pilote charge OpenSSL de manière dynamique, ce qui lui permet de s’exécuter sur des systèmes dotés de la version 1.0 ou 1.1 sans avoir besoin de fichiers de pilote distincts. À partir de la version 17.9, le pilote prend en charge OpenSSL 3.0 en plus des versions précédentes. Lorsqu’il y a plusieurs versions d’OpenSSL, le pilote tente de charger la dernière version.

Version du pilote Versions OpenSSL prises en charge
17.4+ 1.0, 1.1
17.9, 18.0 et ultérieures 1.0, 1.1, 3.0

Notes

Un conflit potentiel peut se produire si l’application qui utilise le pilote (ou l’un de ses composants) est liée à une version différente d’OpenSSL ou la charge dynamiquement. S’il y a plusieurs versions d’OpenSSL sur le système et que l’application l’utilise, il est fortement recommandé de s’assurer que la version chargée par l’application et le pilote ne sont pas incompatibles, car les erreurs peuvent corrompre la mémoire et, par conséquent, ne pas forcément se manifester de manière évidente ou cohérente.

Alpine Linux

Au moment de la rédaction de cet article, la taille de la pile par défaut dans MUSL est de 128 Ko, ce qui est suffisant pour les fonctionnalités de base du pilote ODBC. Toutefois, en fonction des actions effectuées par l’application, il est facile de dépasser cette limite, en particulier lorsque le pilote est appelé à partir de plusieurs threads. Nous vous recommandons de compiler une application ODBC sur Alpine Linux avec -Wl,-z,stack-size=<VALUE IN BYTES> pour augmenter la taille de la pile. Pour référence, la taille de la pile est par défaut de 2 Mo sur la plupart des systèmes GLIBC.

Remarques supplémentaires

  • Vous pouvez établir une connexion administrateur dédiée (DAC) à l’aide de l’authentification SQL Server et de port,hôte. Un membre du rôle Sysadmin doit d’abord découvrir le port DAC. Consultez Connexion de diagnostic pour les administrateurs de base de données pour découvrir la procédure à suivre. Par exemple, si le port DAC était 33000, vous pourriez vous y connecter avec sqlcmd comme suit :

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

    Notes

    Les connexions DAC doivent utiliser l’authentification SQL Server.

  • Le Gestionnaire de pilotes UnixODBC retourne « Identificateur d’option/d’attribut non valide » pour tous les attributs d’instruction quand ils sont transmis par le biais de SQLSetConnectAttr. Sur Windows, quand SQLSetConnectAttr reçoit une valeur d’attribut d’instruction, le pilote est amené à définir cette valeur sur toutes les instructions actives qui sont des enfants du handle de connexion.

  • Lorsque le pilote est utilisé avec des applications fortement multithread, la validation du descripteur d’unixODBC peut devenir un goulot d’étranglement de performances. Dans ce cas de figure, il est possible d’augmenter le niveau de performance en compilant unixODBC avec l’option --enable-fastvalidate. Toutefois, n’oubliez pas que cette option peut entraîner le blocage des applications qui transmettent des descripteurs non valides aux API ODBC, au lieu d’erreurs SQL_INVALID_HANDLE.

Voir aussi

Questions fréquentes (FAQ)
Problèmes connus dans cette version du pilote
Notes de publication