Principales diferencias en la versión del controlador Microsoft ODBC para SQL Server

Este artículo describe los cambios repentinos entre el controlador ODBC 18 de Microsoft para SQL Server y la versión 17. Úsalo cuando elijas una versión de controlador, actualices una aplicación de la versión 17 a la 18, o necesites que una cadena de conexión funcione de forma consistente en ambas versiones.

La mayoría de las aplicaciones que actualizan de la versión 17 a la 18 se ven afectadas por un solo cambio: las conexiones se cifran por defecto. Si tu aplicación deja de conectarse después de actualizar, lee primero el comportamiento de cifrado por defecto .

Elige la versión 17 o la versión 18

El driver 18 es la versión principal actual. El controlador 17 sigue siendo soportado, pero las aplicaciones que lo usan aún necesitan la última versión menor de la línea del controlador 17 para recibir correcciones. Para fechas de soporte y normas de servicio, consulte ciclo de vida de soporte.

Cambiar de versión principal suele significar cambiar el nombre del controlador o el paquete que seleccionas:

Resumen de los cambios

Las filas por defecto y validación describen conexiones remotas ordinarias sin configuración DSNEncrypt, atributo SQL_COPT_SS_ENCRYPT ni la anulación de Cifrado de Windows Force Protocol. LocalDB no es un objetivo remoto TLS.

Cambios de cifrado

Comportamiento de cifrado predeterminado

El controlador 17 se activa por defecto Encrypt=no a menos que la Authentication palabra clave esté asignada a un valor distinto none o la aplicación establezca el SQL_COPT_SS_ACCESS_TOKEN atributo. Cualquiera de las dos cambia el valor por defecto a yes. Un alambique explícito Encrypt=no desactiva el cifrado. El controlador 18.0.1 y posteriores por defecto es Encrypt=yes. Establece Encrypt explícitamente cuando compares versiones.

El cifrado de conexión completa protege el texto de consulta y los resultados, así como el inicio de sesión. Con Encrypt=no, el servidor puede seguir requiriendo cifrado de conexión completa. Cuando tanto el cliente como el servidor seleccionan el cifrado desactivado, la negociación no estricta utiliza cifrado solo de inicio de sesión; esto no protege los datos de la aplicación posteriores.

Con , ambos controladores seleccionan Encrypt=yes;TrustServerCertificate=nola validación normal del certificado del servidor. Si solo el servidor requiere cifrado de conexión completa y TrustServerCertificate=no (por defecto), el controlador 18 valida el certificado. Con TrustServerCertificate=yes el modo Strict fuera de ella, el Driver 18 se salta esa validación. El controlador 17 no se valida únicamente por ese requisito del servidor. El cifrado de Windows Force Protocol y las rutas internas de validación de certificados no están cubiertas por esta comparación.

Con la configuración de cifrado predeterminada, actualizar de la versión 17 a la 18 puede exponer un certificado de servidor no confiable. Si la versión 18 rechaza el certificado, diagnostica la cadena de certificados y el nombre antes de cambiar la configuración de autenticación.

Mantén activada la validación del cifrado y la identidad del servidor:

• Configura un certificado de servidor válido y el almacén de confianza del cliente para que el cliente confíe en su autoridad certificadora emisora. Conéctate usando un nombre en el certificado.
• Si te conectas a través de un alias, pon HostnameInCertificate un nombre válido en el certificado del servidor. Esta configuración no arregla una cadena de certificados no confiable.
• Para Encrypt=Strict, el controlador 18.1 y versiones posteriores también soportan ServerCertificate la comparación del certificado del servidor con un archivo de certificado. Esta configuración fija un certificado; no especifica un nombre de host. Revisa sus restricciones en ODBC DSN y palabras clave de cadena de conexión antes de usarla.

Si una aplicación existente requiere el valor predeterminado de la versión 17 durante una prueba de compatibilidad controlada, consulte Restaurar comportamiento de cifrado de la versión 17. Encrypt=no Y Encrypt=optional no repares la confianza en los certificados y puedes dejar los datos de la aplicación sin cifrar.

Cifrar valores

La versión 17 acepta solo yes y no. La versión 18 y versiones posteriores aceptan esos valores y añaden tres más:

Strict no tiene equivalente a la versión 17. Es el único valor que selecciona TDS 8.0, donde el cifrado se negocia antes del intercambio de inicio de sesión en lugar de durante él.

Restaurar comportamiento de cifrado de la versión 17

Tras revisar las correcciones de confianza, utilice la siguiente configuración solo para una prueba de compatibilidad controlada que permita datos de aplicación no cifrados:

Encrypt=no

El controlador 18 también acepta Encrypt=optional esta configuración. Ninguno de los dos valores impide que el servidor requiera cifrado. Restaurar la configuración cifrada prevista tras la prueba; no usar cifrado desactivado como solución de confianza en el certificado.

Lista de comprobación de actualización

1. Cadenas de conexión de inventario, DSNs, referencias de paquetes y scripts de despliegue que seleccionan el Controlador 17.
2. Instala el controlador 18 en un entorno de prueba que coincida con producción.
3. Cambia la Driver palabra clave de cada cadena de conexión por ODBC Driver 18 for SQL Server, y actualiza o recrea cada DSN para usar el Driver 18. Instalar el controlador 18 no cambia las conexiones existentes, porque las conexiones que nombran el controlador 17 siguen usando el controlador 17.
4. Establezca Encrypt explícitamente. Úsalo Encrypt=Mandatory con validación normal de certificados. Úsalo Encrypt=Strict solo cuando el servidor soporte TDS 8.0, como SQL Server 2022 y versiones posteriores. Para servidores que no soportan TDS 8.0, usa Encrypt=Mandatory.
5. Para una validación normal, conéctate y TrustServerCertificate=no verifica la cadena de confianza y el nombre del servidor aceptado. Para el controlador 18.1 y versiones posteriores con fijación estricta de archivos, verificar la coincidencia exacta del certificado y las fechas de validez; TrustServerCertificate se ignora en modo estricto.
6. Ejecuta las rutas de autenticación, consulta, transacción, copia masiva, conmutación por error y reintentos de la aplicación.
7. Revisa los diagnósticos para detectar errores de validación de certificados antes de tratar los fallos como errores de autenticación o de red.
8. Mantén instalado el controlador 17 y guarda el inventario desde el paso 1 hasta que se complete la validación, para poder revertir a la versión 17.

Volver a la versión 17

El controlador 17 y el controlador 18 se instalan lado a lado, así que puedes revertir sin desinstalar el controlador 18. Para detalles de descarga e instalación, consulta Descargar ODBC Driver para SQL Server.

1. Confirma que el controlador 17 sigue instalado en cada cliente.
2. Usando el inventario de la lista de verificación de actualización, cambia la Driver palabra clave en cada cadena de conexión de nuevo a ODBC Driver 17 for SQL Server.
3. Actualiza o recrea cada DSN para usar el Driver 17.
4. Revertir referencias de paquetes y scripts de despliegue al paquete Driver 17, como msodbcsql17 en Linux.
5. Restaura los Encrypt valores y TrustServerCertificate que la aplicación usó con el controlador 17. El controlador 17 acepta solo yes y no para Encrypt y no reconoce palabras clave del controlador 18 como HostnameInCertificate o ServerCertificate, así que elimina valores y palabras clave añadidas para el controlador 18. Cambiar las palabras clave de alias de nuevo a sus nombres de Driver 17 y reemplazarlas ConnectTimeout por una SQLSetConnectAttr llamada que establezca SQL_ATTR_LOGIN_TIMEOUT. Para el mapeo, consulta New cadena de conexión keywords.

Valida la reversión antes de considerarla completa:

• Cada conexión informa del Driver 17. Llama a SQLGetInfo con SQL_DRIVER_VER; la versión principal es 17.
• Las rutas de autenticación, consulta, transacción, copia masiva, conmutación por error y reintentos de la aplicación tienen éxito.
• Las cadenas de conexión y las DSN no contienen valores Encrypt ni palabras clave añadidas para el Driver 18.

Nuevas palabras clave de cadena de conexión

La versión 18 añade las siguientes palabras clave de cadena de conexión, que la versión 17 no reconoce. Algunos de ellos son nombres nuevos para configuraciones que la versión 17 soporta bajo una palabra clave o atributo diferente, listados en la columna equivalente a la versión 17 .

MultipleActiveResultSets, WorkstationID, y FailoverPartner son alias que alinean los nombres de palabras clave ODBC con Microsoft.Data.SqlClient los nombres de propiedades. La versión 18 también acepta los nombres antiguos. Para más detalles, véase Unificación de la cadena de palabras clave de Conexión y Palabra clave ConnectTimeout.

Para la referencia completa de palabras clave, véase ODBC DSN y palabras clave de cadena de conexión.

Contenido relacionado

• Palabras clave ODBC DSN y cadena de conexión
• controlador ODBC de Microsoft para SQL Server
• Ciclo de vida de soporte técnico
• Notas de versión para ODBC Driver para SQL Server en Windows
• Notas de versión para ODBC Driver para SQL Server en Linux y macOS