Nota
L'accés a aquesta pàgina requereix autorització. Podeu provar d'iniciar la sessió o de canviar els directoris.
L'accés a aquesta pàgina requereix autorització. Podeu provar de canviar els directoris.
Las características de programación de Microsoft ODBC Driver for SQL Server en macOS y Linux se basan en ODBC en SQL Server Native Client (SQL Server Native Client (ODBC)). SQL Server Native Client se basa en ODBC de Windows Data Access Components (Referencia para programadores de ODBC).
Una aplicación ODBC puede usar Conjuntos de resultados activos múltiples (MARS) y otras características específicas de SQL Server al incluir /usr/local/include/msodbcsql.h después de incluir los archivos de encabezado de unixODBC (sql.h, sqlext.h, sqltypes.h y sqlucode.h). Luego use los mismos nombres simbólicos para los elementos específicos de SQL Server que usaría en las aplicaciones de ODBC para Windows.
Características disponibles
Las siguientes secciones de la documentación de SQL Server Native Client para ODBC (SQL Server Native Client (ODBC)) son válidas cuando se usa el controlador ODBC en macOS y Linux:
- Comunicar con SQL Server (ODBC)
- Admite tiempos de espera de conexión y consulta
- Cursores
- Mejoras de fecha y hora (ODBC)
- Ejecutar consultas (ODBC)
- Controlar errores y mensajes
- Autenticación Kerberos
- Tipos CLR grandes definidos por el usuario (ODBC)
- Realización de transacciones (ODBC) (excepto las transacciones distribuidas)
- Resultados del procesamiento (ODBC)
- Ejecutar procedimientos almacenados
- Compatibilidad con columnas dispersas (ODBC)
- Utilizar el cifrado sin validación
- Parámetros con valores de tabla
- UTF-8 y UTF-16 para la API de datos y comandos
- Utilizar funciones de catálogo
Características no admitidas
Las siguientes características no se han verificado para funcionar correctamente con el controlador ODBC en macOS y Linux:
- Conexión al clúster de conmutación por error
- Resolución de IP de red transparente (antes, versión 17 del controlador ODBC)
- Seguimiento de BID del controlador ODBC para Linux y macOS (antes del controlador ODBC 17.3)
Las siguientes características no están disponibles en el controlador ODBC en macOS y Linux:
- Transacciones distribuidas (no se admite el atributo SQL_ATTR_ENLIST_IN_DTC)
- Creación de reflejo de la base de datos
- FILESTREAM
- Generación de perfiles de rendimiento del controlador ODBC, que se describe en SQLSetConnectAttr, y los siguientes atributos de conexión relacionados con el rendimiento:
- 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 (antes de la versión 17.2)
- Tipos de intervalo de C como SQL_C_INTERVAL_YEAR_TO_MONTH (documentado en Identificadores y descriptores de tipo de datos)
- El valor SQL_CUR_USE_ODBC del atributo SQL_ATTR_ODBC_CURSORS de la función SQLSetConnectAttr.
Compatibilidad con conjuntos de caracteres
Para la versión 13 y 13.1 del controlador ODBC, los datos de SQLCHAR deben ser UTF-8. No se admite ninguna otra codificación.
Para la versión 17 del controlador ODBC, se admiten datos de SQLCHAR en una de las siguientes codificaciones o conjuntos de caracteres:
Nota
Debido a diferencias de iconv en musl y glibc, muchas de estas configuraciones regionales no son compatibles con Alpine Linux.
Para más información, consulte Diferencias funcionales con respecto a glibc
| Nombre | Descripción |
|---|---|
| UTF-8 | Unicode |
| CP437 | MS-DOS Latinoamericano de EE. UU. |
| CP850 | MS-DOS Latín 1 |
| CP874 | Latín/tailandés |
| CP932 | Japonés, Shift-JIS |
| CP936 | Chino simplificado, GBK |
| CP949 | Coreano, EUC-KR |
| CP950 | Chino tradicional, Big5 |
| CP1251 | Cirílico |
| CP1253 | Griego |
| CP1256 | Árabe |
| CP1257 | Báltico |
| CP1258 | Vietnamita |
| ISO-8859-1 / CP1252 | Latín-1 |
| ISO-8859-2 / CP1250 | Latín-2 |
| ISO-8859-3 | Latín-3 |
| ISO-8859-4 | Latín-4 |
| ISO-8859-5 | Latín/cirílico |
| ISO-8859-6 | Latín/árabe |
| ISO-8859-7 | Latín/griego |
| ISO-8859-8 / CP1255 | Hebreo |
| ISO-8859-9 / CP1254 | Turco |
| ISO-8859-13 | Latín-7 |
| ISO-8859-15 | Latín-9 |
Al conectarse, el controlador detecta la configuración regional actual del proceso en el que está cargado. Si utiliza una de las codificaciones anteriores, el controlador utiliza esa codificación para los datos de SQLCHAR (caracteres estrechos). En caso contrario, el valor predeterminado es UTF-8. Dado que todos los procesos empiezan de forma predeterminada en la configuración regional "C" (y esto hace que el valor predeterminado del controlador sea UTF-8), si una aplicación necesita utilizar una de las codificaciones anteriores, debe usar la función setlocale para establecer la configuración regional adecuadamente antes de conectarse, ya sea especificando la configuración regional de forma explícita o mediante una cadena vacía, como setlocale(LC_ALL, ""), para usar la configuración regional del entorno.
Por lo tanto, en un entorno típico de Linux o macOS, donde la codificación es UTF-8, los usuarios de la versión 17 del controlador ODBC que actualizan desde la versión 13 o 13.1 no observarán ninguna diferencia. Sin embargo, las aplicaciones que usan una codificación que no es UTF-8 en la lista anterior a través de setlocale() deben usar esa codificación para los datos hacia y desde el controlador en lugar de UTF-8.
Los datos de SQLWCHAR deben tener la codificación UTF-16LE (Little Endian).
Al enlazar parámetros de entrada con SQLBindParameter, si se especifica un carácter estrecho de tipo SQL como SQL_VARCHAR, el controlador convierte los datos proporcionados en la codificación del cliente a la codificación SQL Server (normalmente, la página de códigos 1252) predeterminada. Para los parámetros de salida, el controlador lleva a cabo la conversión desde la codificación especificada en la información de intercalación asociada con los datos a la codificación del cliente. Sin embargo, es posible que se pierdan datos: los caracteres de la codificación de origen que no se puedan representar en la codificación de destino se convertirán en un signo de interrogación ("?").
Para evitar que se pierdan datos al enlazar parámetros de entrada, especifique un tipo de carácter Unicode SQL, como SQL_NVARCHAR. En este caso, el controlador lleva a cabo la conversión desde la codificación del cliente en UTF-16, con el que se pueden representar todos los caracteres Unicode. Además, la columna de destino o el parámetro en el servidor debe ser también un tipo de Unicode (nchar, nvarchar, ntext) o uno con una intercalación o codificación, que puede representar todos los caracteres de los datos de origen. Para evitar que se pierdan datos con los parámetros de salida, especifique un tipo SQL de Unicode y un tipo C de Unicode (SQL_C_WCHAR), que haga que el controlador devuelva datos como UTF-16, o bien un tipo C estrecho, y asegúrese de que la codificación del cliente puede representar todos los caracteres del origen de datos (esta representación siempre es posible con UTF-8).
Para obtener más información sobre los cotejamientos y las codificaciones, consulte Compatibilidad con cotejamientos y Unicode.
Hay algunas diferencias de conversión de codificación entre Windows y varias versiones de la biblioteca de iconv en Linux y macOS. Los datos de texto en la página de códigos 1255 (hebreo) tienen un punto de código (0xCA) que se comporta de forma distinta durante la conversión a Unicode. En Windows, este carácter se convierte en el punto de código UTF-16 de 0x05BA. En macOS y Linux con versiones de libiconv anteriores a 1.15, se convierte en 0x00CA. En equipos Linux con bibliotecas de iconv que no admiten la revisión de 2003 de Big5/CP950 (denominada BIG5-2003), los caracteres agregados con esa revisión no se convierten correctamente. En la página de códigos 932 (japonés, Shift-JIS), el resultado de la descodificación de caracteres que no se definen originalmente en el estándar de codificación también difiere. Por ejemplo, el byte 0x80 se convierte en U+0080 en Windows, pero puede llegar a ser U+30FB en Linux y macOS, según la versión de iconv.
En ODBC Driver 13 y 13.1, cuando los caracteres UTF-8 de varios bytes o los pares suplentes de UTF-16 se dividen entre búferes de SQLPutData, se produce corrupción de datos. Los búferes se utilizan para transmitir datos de SQLPutData sin codificaciones de caracteres parciales. Esta limitación se ha quitado con la versión 17 del controlador ODBC.
Openssl
A partir de la versión 17.4, el controlador carga OpenSSL de manera dinámica, lo que permite que se ejecute en sistemas que tienen la versión 1.0 o 1.1 sin necesidad de archivos de controlador independientes. A partir de la versión 17.9, el controlador admite OpenSSL 3.0 además de las versiones anteriores. Cuando hay varias versiones de OpenSSL presentes, el controlador intentará cargar la más reciente.
| Versión del controlador | Versiones de OpenSSL admitidas |
|---|---|
| 17.4+ | 1.0, 1.1 |
| 17.9, 18.0+ | 1.0, 1.1, 3.0 |
Nota
Puede producirse un posible conflicto si la aplicación que usa el controlador (o uno de sus componentes) está vinculada a una versión diferente de OpenSSL o si la carga de manera dinámica. Si hay varias versiones de OpenSSL presentes en el sistema y la aplicación utiliza OpenSSL, es muy recomendable extremar las precauciones para asegurarse de que la versión de OpenSSL que carga la aplicación y la que carga el controlador no sean distintas, ya que los errores podrían corromper la memoria y, por lo tanto, no necesariamente se manifestarán de formas evidentes o coherentes.
Alpine Linux
En el momento de redactar este documento, el tamaño predeterminado de la pila en MUSL es 128 K, que es suficiente para la funcionalidad básica del controlador ODBC, pero en función de lo que hace la aplicación no es difícil superar este límite, especialmente cuando se llama al controlador desde varios subprocesos. Se recomienda compilar una aplicación ODBC en Alpine Linux con -Wl,-z,stack-size=<VALUE IN BYTES> para aumentar el tamaño de la pila. Como referencia, el tamaño predeterminado de la pila en la mayoría de los sistemas GLIBC es de 2 MB.
Notas adicionales
Puede realizar una conexión de administrador dedicada (DAC) con la autenticación de SQL Server y host,port. Un miembro de la función Sysadmin debe detectar primero el puerto DAC. Para descubrir cómo, consulte Conexión de diagnóstico para administradores de bases de datos. Por ejemplo, si el puerto DAC fuera 33000, podría conectarse a él con
sqlcmdde la siguiente forma:sqlcmd -U <user> -P <pwd> -S <host>,33000Nota
Las conexiones DAC deben usar la autenticación de SQL Server.
El gestor de controladores UnixODBC devuelve el mensaje "identificador de atributo/opción no válido" para todos los atributos de sentencia cuando se pasan mediante SQLSetConnectAttr. En Windows, cuando SQLSetConnectAttr recibe un valor de atributo de instrucción, el controlador tiene que establecer ese valor en todas las instrucciones activas que son elementos secundarios del identificador de conexión.
Al usar el controlador con aplicaciones multiproceso, la validación del identificador de unixODBC puede convertirse en un cuello de botella de rendimiento. En estos escenarios, se puede obtener más rendimiento mediante la compilación de unixODBC con la opción
--enable-fastvalidate. Sin embargo, tenga en cuenta que esta opción puede provocar que las aplicaciones que pasan identificadores no válidos a las API de ODBC se bloqueen en lugar de devolver errores deSQL_INVALID_HANDLE.