Preguntas frecuentes sobre ODBC en Linux y macOS

Utiliza el controlador ODBC 18 de Microsoft para SQL Server, la línea actual de controladores, para nuevos desarrollos. El controlador ODBC 17 de Microsoft para SQL Server sigue teniendo soporte para las aplicaciones que ya lo implementan, tal y como se describe en el ciclo de vida de soporte.

El cambio de actualización que afecta a la mayoría de las aplicaciones es que Driver 18 cifra las conexiones por defecto. Para todas las diferencias, véase Diferencias entre versiones principales.

El controlador 18 soporta estos sistemas operativos y arquitecturas de procesador:

Las versiones del sistema operativo compatibles cambian con cada lanzamiento de controladores. Para la tabla por versiones, consulte Requisitos del sistema.

El controlador en Linux y macOS soporta la mayoría de las funciones de SQL Server. No admite la inscripción en transacciones distribuidas mediante el atributo SQL_ATTR_ENLIST_IN_DTC, la duplicación de bases de datos, FILESTREAM ni los atributos de perfilado de rendimiento del controlador. LocalDB no está disponible en Linux ni en macOS. Las transacciones XA a través del Coordinador de Transacciones Distribuidas (DTC) están soportadas a partir del controlador 17.3. Para más información, consulte Usar transacciones XA con DTC. Para la lista completa, véase Limitaciones.

No. El controlador Microsoft ODBC para SQL Server no es de código abierto.

El driver utiliza el gestor de drivers unixODBC. Cuando instalas el controlador 17 o 18 con el gestor de paquetes o Homebrew de tu plataforma, unixODBC se instala como una dependencia. Sigue los pasos para Linux o macOS.

En macOS, compila y ejecuta tu aplicación con unixODBC en lugar de iODBC. Haga coincidir la arquitectura del procesador de la aplicación, el administrador de controladores y el controlador. Un error como incompatible architecture (have 'arm64', need 'x86_64') indica una descoordinación arquitectónica, no necesariamente el gestor de drivers incorrecto.

Ejecuta odbcinst -q -d para listar los controladores registrados. La salida muestra el nombre de cada controlador exactamente tal y como debe aparecer en la cadena de conexión:

[ODBC Driver 18 for SQL Server]

Ejecuta odbcinst -j para mostrar la versión de unixODBC y las rutas de odbcinst.ini, que registra los controladores, y odbc.ini, que contiene los nombres de origen de datos (DSN) del sistema y del usuario:

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

Para configurar una DSN, consulta Cadenas de conexión y DSN.

El error se ve así:

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

Revisa estas causas en orden:

1. El Driver valor en la cadena de conexión o DSN no coincide con el nombre del controlador registrado. Ejecuta odbcinst -q -d y copia el nombre exactamente.
2. Tu aplicación utiliza archivos de configuración diferentes a los que editaste. Ejecuta odbcinst -j desde el mismo entorno que la aplicación y comprueba qué gestor de controladores carga la aplicación. En macOS, crea enlaces simbólicos de configuración solo si la aplicación los necesita, como se describe en Solución de problemas en macOS.
3. Hay más de una copia del gestor de controladores unixODBC instalada, y tu aplicación carga la incorrecta. En Linux, ejecute find /usr -name 'libodbc*.so*'. En macOS, ejecuta find /opt/homebrew /usr/local -name 'libodbc*.dylib'. Múltiples rutas por sí solas no demuestran que haya varios administradores de controladores instalados: los enlaces de Homebrew pueden apuntar a la misma biblioteca en su directorio Cellar. Comprueba qué librería carga realmente la aplicación. Para más información, consulta Solucionar problemas de conexión.

El controlador 18 se establece de forma predeterminada en Encrypt=yes. El controlador 17 utiliza Encrypt=no de forma predeterminada solo cuando no se proporciona una configuración Authentication no vacía ni un token de acceso. Una configuración no vacía Authentication, incluyendo Authentication=SqlPassword, o un token de acceso cambia el valor predeterminado de Driver 17 a Encrypt=yes. Las configuraciones explícitas de cifrado anulan estos valores predeterminados.

Revisa los ajustes efectivos en tu cadena de conexión, DSN y atributos de preconexión configurados a través de SQLSetConnectAttr. Por ejemplo, Encrypt=yes en un DSN o SQL_COPT_SS_ENCRYPT=SQL_EN_ON solicita cifrado incluso cuando la cadena de conexión omite Encrypt. Suministra tokens de acceso solo a través del SQL_COPT_SS_ACCESS_TOKEN atributo de conexión, no de una palabra clave de cadena de conexión.

Con Encrypt=yes y TrustServerCertificate=no, ambos controladores cifran la conexión y validan el certificado del servidor. Con Encrypt=no, el controlador 17 no valida el certificado, mientras que el controlador 18 lo valida si el servidor fuerza el cifrado y TrustServerCertificate=no. Por lo tanto, una conexión que anteriormente utilizara el valor predeterminado Encrypt=no del controlador 17 puede fallar con el controlador 18 al conectarse a un servidor con un certificado autofirmado o que, por cualquier otro motivo, no sea de confianza. Con un certificado autofirmado, el error del Driver 18 se ve así:

[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

Es preferible utilizar un certificado de confianza o la fijación de certificados. Utiliza estas opciones:

• Instala un certificado en el servidor emitido por una autoridad certificadora en la que el cliente confíe. Si el certificado es de confianza pero su nombre no coincide con el valor Server, fija HostNameInCertificate en el nombre que figura en el certificado. HostNameInCertificate Solo cambia el nombre esperado, así que no arregla un certificado autofirmado.
• Con el controlador 18.1 y versiones posteriores y un servidor que admite Tabular Data Stream (TDS) 8.0, establezca Encrypt=strict y establezca ServerCertificate en la ruta de una copia del certificado del servidor. De este modo, el controlador solo acepta ese certificado concreto. ServerCertificate solo funciona en modo estricto.
• Configura Encrypt=no solo si aceptas tráfico de aplicaciones no cifrado cuando el servidor no fuerza el cifrado. Esto coincide con el valor predeterminado del Driver 17 solo cuando no se proporciona ningún ajuste no vacío Authentication ni token de acceso y no se activa la anulación de cifrado. Si el servidor fuerza el cifrado, el controlador 18 sigue validando el certificado a menos que TrustServerCertificate=yes deshabilite la validación.

Para más información, véase Comportamiento de cifrado por defecto.

Sí. Consigue un ticket de Kerberos con kinit, y luego conéctate con Trusted_Connection=yes en la cadena de conexión o DSN. La instancia de SQL Server necesita un nombre principal de servicio (SPN) registrado. Para los pasos de configuración, consulte Usar autenticación integrada.

Sí, para Azure SQL Database, Azure SQL Managed Instance y SQL Server 2022 y versiones posteriores. Para configurar SQL Server, incluso a través de Azure Arc, utiliza la autenticación Microsoft Entra para SQL Server. En Linux y macOS, Driver 17 y versiones posteriores soportan estos métodos:

• Identidad gestionada, con Authentication=ActiveDirectoryMsi, comenzando con Driver 17.3.
• Entidad de servicio, con Authentication=ActiveDirectoryServicePrincipal, a partir de la versión 17.7 del controlador.
• Autenticación integrada mediante Kerberos en un entorno federado, con Authentication=ActiveDirectoryIntegrated, a partir del controlador 17.6.
• Un token de acceso que obtiene tu aplicación, y que se pasa mediante el atributo de conexión SQL_COPT_SS_ACCESS_TOKEN.

ActiveDirectoryInteractiveestá disponible solo en el controlador de Windows. ActiveDirectoryPassword está obsoleto. La autenticación gestionada por drivers en Linux y macOS no soporta escenarios que requieran políticas de acceso condicional. Si tu aplicación adquiere un token de acceso por separado, la biblioteca de autenticación y las políticas de Microsoft Entra ID rigen esa adquisición de token. Pasa el token por SQL_COPT_SS_ACCESS_TOKEN.

En Alpine Linux, la autenticación integrada requiere una libcurl compilación con soporte para el Mecanismo de Negociación de Interfaz de Aplicación de Servicio Genérico de Seguridad Simple y Protegido (SPNEGO). Comprueba las capacidades instaladas libcurl en lugar de asumir que el paquete por defecto lo soporta.

Para cadenas de conexión y ejemplos de código, véase Usar Microsoft Entra ID con el controlador ODBC.

Sí. Una aplicación escrita para la interfaz de programación de aplicaciones (API) ODBC y compilada con unixODBC puede cargar este controlador. Para utilizar funciones específicas de SQL Server, incluye msodbcsql.h después de las cabeceras unixODBC. Para comandos de compilador y nombres de librería, véase Desarrollar aplicaciones en C y C++ con el controlador ODBC.

Sí. Conectarse y realizar consultas con C++ y ODBC compila y ejecuta un ejemplo en Linux, macOS y Windows.

Los archivos de traza pueden contener datos sensibles. Con la cuenta que ejecuta la aplicación, cree un directorio al que solo pueda acceder dicha cuenta:

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

Añade estos ajustes a la [ODBC] sección de odbcinst.ini. Sustituye /home/<user>/odbc-trace/odbctrace.log por el camino absoluto dentro del directorio que has creado. En macOS, los directorios personales suelen usar /Users/<user> en lugar de /home/<user>.

Mantén la ruta completa del archivo trazado a 62 bytes o menos para evitar el truncamiento por unixODBC.

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

Estas configuraciones habilitan el rastreo para las aplicaciones que usan esta configuración de gestor de controladores, y el rastreo las ralentiza. Utiliza un directorio privado separado para cada cuenta de aplicación. Elimina Trace = Yes cuando termines y elimina los archivos de traza que ya no necesites. Para el rastreo por aplicación, véase Rastreo de acceso a datos en Linux y macOS.

Usa UTF-16LE (little endian) para los datos SQLWCHAR. Utiliza búferes UTF-16 SQLWCHAR con las APIs ODBC de carácter ancho en lugar del tipo nativo wchar_t , que es de 32 bits en Linux y macOS.

Utilice UTF-8 para los datos SQLCHAR. A partir del controlador 17, el controlador también acepta un conjunto de páginas de códigos de un byte y de dos bytes para los datos SQLCHAR cuando la configuración regional del proceso selecciona una de ellas. Los procesos comienzan en la C configuración regional, por lo que el controlador usa UTF-8 a menos que la aplicación llame a setlocale. Para ver la lista de codificaciones, consulte Administrar datos de caracteres.