Solucionar problemas de Microsoft OLE DB Driver for SQL Server

Se aplica a:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Base de datos de Azure SQL en Microsoft Fabric

Utiliza este artículo para identificar la etapa fallida de una operación de OLE DB, elegir la siguiente comprobación y encontrar instrucciones detalladas de solución de problemas. La guía utiliza al proveedor actual, MSOLEDBSQL19. Para defectos específicos de la versión y cambios de actualización, consulte Problemas conocidos y Diferencias principales en la versión.

Identificar el síntoma

Captura la descripción completa del error y todos los registros de error disponibles antes de cambiar la configuración. Un nivel HRESULTsuperior , como DB_E_ERRORSOCCURRED, no identifica la causa por sí solo. Registra si el fallo se produce al cargar el proveedor, abrir una conexión, ejecutar un comando, obtener datos o confirmar una transacción.

Síntoma	Comience aquí
No se puede encontrar el proveedor, o la clase no está registrada.	Registro y arquitectura de proveedores
El inicio de sesión falla, el acceso se deniega o falla la autenticación integrada.	Fallos en el inicio de sesión y la autenticación
La cadena de certificados no es de fiar, o el nombre del certificado no coincide.	Fallos en los certificados TLS
No se puede encontrar el servidor ni la instancia, o se rechaza la conexión.	Fallos de detección de red e instancias
Se producen errores en los parámetros, los valores se truncan o los datos no se pueden convertir.	Errores de parámetros y conversión de datos
Se cae la conexión, falla la recuperación o expira un tiempo de espera.	Pérdida de conexión y tiempos de espera
Faltan detalles de error o necesitas un rastreo para soporte.	Diagnóstico y seguimiento

Para fallos de conexión, compara la aplicación con una prueba de conexión Universal Data Link (UDL). Utiliza el mismo ordenador, proveedor, arquitectura de procesos, identidad de autenticación, servidor, base de datos y configuración de cifrado. Una prueba exitosa con otro proveedor o identidad no demuestra que la configuración de la aplicación funcione.

Registro y arquitectura de proveedores

Errores como No se puede encontrar el proveedor o REGDB_E_CLASSNOTREG (0x80040154, Clase no registrada) indican que el proveedor se carga antes de la autenticación de SQL Server.

Comprueba el proveedor que solicita la aplicación. MSOLEDBSQL19 y MSOLEDBSQL identifican diferentes versiones principales. Instalar el controlador actual no cambia la selección de proveedor de una aplicación. Sigue los pasos de migración si la aplicación sigue solicitando otro proveedor.
Comprueba la arquitectura del proceso que aloja la aplicación. Una aplicación de 32 bits necesita el proveedor de 32 bits, incluso en Windows de 64 bits. Para un servicio o trabajo programado, comprueba el ejecutable y la cuenta que usa ese host, no solo tu entorno de desarrollo.
Instala o repara el controlador con el instalador compatible en el ordenador que ejecuta la aplicación. El instalador x64 incluye binarios de controladores de 64 y 32 bits. Comprueba las dependencias requeridas en Instalar el controlador OLE DB y los requisitos del sistema. No copies librerías de controladores de otro ordenador como sustituto de la instalación.
Repite la prueba UDL con la arquitectura y el proveedor correspondientes. Si funciona pero la aplicación aún no puede cargar al proveedor, compara la selección efectiva del proveedor y la arquitectura del host de la aplicación con la prueba.

Si el error nombra adal.dllespecíficamente , comprueba el problema conocido de la librería de autenticación en lugar de tratarlo como un proveedor de SQL Server ausente.

Distingue un rechazo de inicio de sesión de servidor de un fallo en obtener credenciales o establecer una conexión cifrada. Lee el texto completo del error, incluido cualquier error anidado del proveedor.

Para el error de SQL Server 18456, pida al administrador de la base de datos que inspeccione la entrada y estado correspondiente del registro de error del servidor. Comprueba el modo de autenticación, el estado de acceso, la base de datos solicitada y el acceso a la base de datos usando MSSQLSERVER_18456. No asumas que cada rechazo de inicio de sesión significa una contraseña incorrecta.
Para la autenticación integrada, confirma la identidad bajo la cual se ejecuta la aplicación. Una cuenta de servicio o cuenta de tareas programadas puede diferir del usuario que probó con éxito la conexión. Si el mensaje incluye No puede generar contexto SSPI, siga la solución de problemas de la Interfaz de Soporte de Soporte de Seguridad (SSPI) y el soporte de Nombre Principal de Servicio (SPN).
Para Microsoft Entra ID, comprueba que el método de autenticación seleccionado se ajusta al entorno de ejecución de la aplicación y que su identidad tiene acceso a la base de datos de destino. Revisa la configuración específica del método y las restricciones del token de acceso en Use Microsoft Entra ID. No combines un token de acceso con propiedades de autenticación o credenciales contradictorias.
Compara los ajustes efectivos con la tabla correcta de palabras clave de la cadena de conexión. IDBInitialize::Initialize, IDataInitialize::GetDataSource, y los Objetos de Datos ActiveX (ADO) utilizan tablas de palabras clave diferentes. Consulta la tabla de la interfaz que utiliza tu aplicación.

El texto El nombre principal objetivo es incorrecto puede aparecer en diferentes contextos. Si va acompañado de No se puede generar el contexto SSPI, investigue la autenticación de Windows y los SPN. Si el error identifica el certificado o el handshake de cifrado, utilice la siguiente sección.

Fallos en los certificados TLS

Los errores de Seguridad en la Capa de Transporte (TLS) pueden ocurrir antes de que un inicio de sesión llegue a SQL Server. El controlador actual permite el cifrado obligatorio por defecto, por lo que una actualización puede exponer un problema de confianza en el certificado o de nombres que una configuración de conexión anterior no detectó.

Para que la cadena de certificados fue emitida por una autoridad que no es de confianza, comprueba el certificado que presenta SQL Server y la cadena de certificados emisora en la que confía el ordenador cliente. Configura un certificado de servidor válido e instala los certificados raíz e intermedios de confianza requeridos a través del proceso de gestión de certificados de tu organización.
Para una discrepancia de nombres de certificado, compare el nombre del servidor o oyente que utiliza la aplicación con los nombres del certificado. Utiliza un certificado que cubra el nombre de la conexión previsto. Si la aplicación utiliza intencionadamente un nombre de conexión diferente, revise la propiedad documentada HostNameInCertificate antes de configurar el nombre esperado del certificado.
Comprueba los ajustes efectivos de cifrado y validación, incluyendo los ajustes del registro. Revisa las tablas de cifrado y validación de certificados para ver la precedencia y Strict el comportamiento. En el Strict modo, el controlador valida el certificado independientemente de la configuración de trust-server-certificate.
Si el fallo comenzó durante la migración, comprueba la solución de problemas de versiones principales, incluido el tipo de valor de la propiedad de cifrado y la restricción sobre el uso de ServerCertificate fuera del modo Strict.

Consulte Requisitos de certificados para SQL Server y Solución de problemas de confianza de la cadena de certificados para realizar comprobaciones detalladas. Mantén activadas las cifras y la validación de certificados en producción. Desactivar cualquiera de los dos no soluciona un problema de despliegue de certificados.

Fallos de detección de la red y de las instancias

Para servidor no encontrado, error al localizar el servidor o la instancia especificados o errores de conexión rechazada, identifica el extremo al que la aplicación intenta llegar.

Verifica el nombre del servidor, el nombre de la instancia y el puerto de escucha configurado con el administrador de la base de datos. Confirma que el servicio de base de datos está en funcionamiento y que el protocolo y el oyente previstos están habilitados. No asumas que todas las instancias escuchan en el puerto 1433.
Para una conexión TCP remota, pruebe el punto de conexión conocido usando el formato tcp:<server>,<port> server-name del controlador. Mantén la misma autenticación, base de datos y configuración de cifrado. Consulta Palabras clave de la cadena de conexión para ver la palabra clave del servidor correspondiente a tu interfaz.
Si el servidor especificado explícitamente y el puerto funcionan, pero la instancia con nombre no, investiga SQL Server Browser y la detección de instancias. Compruebe el servicio Browser y la ruta del puerto 1434 del Protocolo de datagramas de usuario (UDP) cuando se utilice la detección de Browser.
Si el endpoint explícito también falla, comprueba la resolución del Sistema de Nombres de Dominio (DNS), el enrutamiento y el acceso al firewall al puerto real de escucha desde el host de la aplicación. Sigue los errores de conexión relacionados con la red o específicos de la instancia en lugar de cambiar varios ajustes de conexión a la vez.

Para una escucha de un grupo de disponibilidad, consulte también Soporte para alta disponibilidad y recuperación ante desastres. Para LocalDB, utiliza el soporte de LocalDB para comprobar la instancia local y el contexto del usuario en lugar de aplicar pasos remotos de descubrimiento TCP.

Errores de parámetros y conversión de datos

Si la conexión se abre pero falla la ejecución de comandos o la recuperación de datos, reduce la reproducción al comando y valor fallidos. Conserva el tipo de dato original, la longitud, el estado nulo y la codificación de caracteres al reemplazar datos sensibles.

Compara cada ? marcador de parámetro con su ordinal de enlace, dirección y metadatos. Cuando usas ICommandWithParameters::SetParameterInfo, empareja el tipo de código fuente SQL con el comando o procedimiento almacenado. No asumas que los metadatos de los parámetros siempre se derivan automáticamente. Revisa los parámetros de Command para detectar restricciones de derivación y comportamiento de los parámetros de salida.
Inspeccione los estados de vinculación de los accesores y el estado y la longitud de cada uno de los valores devueltos, no solo el HRESULT general. En caso de fallos en la asignación de propiedades, inspecciona el dwStatus de cada propiedad. Una devolución de éxito parcial como DB_S_ERRORSOCCURRED puede requerir inspección de un array de estado incluso cuando no hay objeto de error disponible. Ver códigos de retorno.
Para la conversión o truncamiento, compara el tipo y tamaño del buffer del consumidor con los metadatos reales de la columna o parámetro. Comprueba la precisión y la escala para valores numéricos, rangos válidos y fracciones de segundo para valores de fecha/hora, y longitudes de bytes para búferes de caracteres. Investiga DBSTATUS_E_CANTCONVERTVALUE y no trates DBSTATUS_S_TRUNCATED como un valor completo. Utiliza mapeo de tipos de datos, filas de obtención y conversiones de fecha y hora para las reglas aplicables.
Si aparecen que faltan parámetros de salida limitados, agota los conjuntos de filas retornados antes de leerlos. Seguir Usa IMultipleResults para procesar múltiples conjuntos de resultados. Para los parámetros de salida transmitidos, consume o libera los flujos pendientes antes de solicitar el siguiente resultado, como se describe en soporte de streaming para parámetros de salida.

Para mapeos específicos de ADO, revisa Use ADO con el controlador OLE DB y las restricciones de autenticación en DataTypeCompatibilityUse Microsoft Entra ID. No añadas una configuración de compatibilidad sin marcar ambas.

Para cadenas estrechas corrompidas en una columna sql_variant tras una actualización del controlador, revisa el problema conocido y el procedimiento de recuperación existente de SSVARIANT antes de modificar los datos almacenados.

Pérdida de conexión y tiempos de espera

Anota cuándo funcionó por última vez la conexión, qué operación falló y cuánto duró esa operación. Distingue estos casos antes de cambiar la configuración de reintento o de tiempo de espera.

Etapa fallida	Comprobaciones y orientación detallada
Apertura de una conexión.	Primero inspecciona los errores del proveedor, la red, la autenticación y el TLS. Comprueba el `DBPROP_INIT_TIMEOUT` efectivo o la palabra clave de conexión correspondiente. Consulta la solución de problemas de tiempo de espera de la conexión.
Ejecutar un comando.	Comprueba `DBPROP_COMMANDTIMEOUT` o la configuración del tiempo de espera de los comandos de la aplicación. Investiga los bloqueos y el rendimiento de las consultas con la solución de problemas de tiempo de espera de consultas. Aumentar el tiempo de espera de la conexión no cambia el tiempo de espera del comando.
Reutilizar una conexión inactiva.	Comprueba las condiciones de recuperación, la configuración de reintentos y los errores esperados en la resiliencia de la conexión en reposo. La recuperación puede fallar cuando expira el tiempo de espera del comando antes de que se complete la reconexión.
Pérdida de conexión durante la ejecución o el commit.	Correlaciona los eventos del cliente y del servidor para comprobar si hay interrupciones de red, reinicio del servidor o conmutación por error. Establece el resultado de la operación antes de decidir si es seguro volver a intentarlo.

La resiliencia de la conexión inactiva no ofrece reintentos de conexión inicial ni reproducción automática de comandos y transacciones arbitrarias. Para un fallo transitorio confirmado, utiliza reintentos limitados de la aplicación con un intervalo de espera y registra cada intento. No intentes repetidamente errores de carga del proveedor, credenciales rechazadas o fallos de validación de certificados sin corregir la causa.

Caution

Si una conexión se interrumpe durante una escritura o una confirmación, el cliente podría no saber si SQL Server confirmó la transacción. No reproduzcas la operación a ciegas. Comprueba su resultado o utiliza un diseño de aplicación que evite efectos duplicados antes de volver a intentarlo.

Diagnósticos y seguimiento

Recoge diagnósticos en el punto de fallo, antes de que llamadas a proveedores no relacionados sustituyan la información de error.

Capturar la operación que falló, la marca de tiempo y la zona horaria, el tiempo transcurrido, y HRESULT. Para los consumidores nativos de OLE DB, recupera todos los registros disponibles a través de IErrorInfo y IErrorRecords, no solo la primera descripción. Incluya SQLSTATE y el número de error nativo de SQL Server cuando esté disponible mediante ISQLErrorInfo. Consulte Obtener información del error y detalles del error de SQL Server. Para ADO, capture la colección de la Errors conexión.
Recopila estados por propiedad, por enlace y por valor para métodos que reportan errores de esa manera. Un objeto de error ausente no hace que un resultado de éxito parcial sea seguro de ignorar.
Correlaciona el fallo del cliente con el registro de errores del servidor o Eventos Extendidos. Cuando esté disponible, registra ClientConnectionID y ActivityID. Un fallo antes del preinicio de sesión puede ocurrir sin un identificador de conexión de cliente.
Si los registros de errores no son suficientes, utiliza Acceder a la información de diagnóstico en el registro de Extended Events para el seguimiento del controlador y la configuración de la correlación. Recoge una traza acotada alrededor de la reproducción y deja de trazar después.

Cuando escales, incluye la versión del controlador, el proveedor solicitado, la arquitectura de la aplicación y el proceso, la versión del servidor, el método de autenticación, la configuración efectiva de conexión, la fase de fallo, los registros de error y una reproducción mínima. Indica si la prueba UDL coincidente tiene éxito y si el problema afecta a un host o a varios hosts.

Elimina contraseñas, tokens de acceso y otros secretos de la configuración de conexión y los registros. Revisa los rastros de texto de consulta y datos sensibles, guárdalos con acceso restringido y compártelos solo a través de un canal de soporte aprobado.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-09-23