Résoudre les problèmes liés au pilote OLE DB Microsoft pour SQL Server

S’applique à :SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Base de données SQL dans Microsoft Fabric

Utilisez cet article pour identifier l’étape défaillante d’une opération OLE DB, choisir la vérification suivante et trouver des instructions détaillées de dépannage. Les recommandations utilisent le fournisseur actuel, MSOLEDBSQL19. Pour les défauts spécifiques à la version et les modifications de mise à jour, voir Problèmes connus et Différences majeures de version.

Identifier le symptôme

Capturez la description complète de l’erreur et tous les enregistrements d’erreur disponibles avant de modifier les paramètres. Un niveau HRESULTsupérieur , comme DB_E_ERRORSOCCURRED, n’identifie pas la cause à lui seul. Notez si la défaillance survient lors du chargement du fournisseur, de l’ouverture d’une connexion, de l’exécution d’une commande, de la récupération de données ou de l’envoi d’une transaction.

Symptôme	Commencer ici
Le fournisseur est introuvable, ou la classe n’est pas enregistrée.	Enregistrement et architecture des fournisseurs
La connexion échoue, l’accès est refusé, ou l’authentification intégrée échoue.	Échecs de connexion et d’authentification
La chaîne de certificats n’est pas fiable, ou le nom du certificat ne correspond pas.	Défaillances des certificats TLS
Le serveur ou l’instance ne peut pas être trouvé, ou la connexion est refusée.	Défaillances de découverte réseau et d’instances
Les paramètres échouent, les valeurs sont tronquées, ou les données ne peuvent pas être converties.	Erreurs de paramètres et de conversion de données
La connexion tombe, la récupération échoue, ou un délai expire.	Pertes de connexion et délais d’attente
Les détails d’erreur manquent, ou vous avez besoin d’une trace pour le support.	Diagnostic et traçage

Pour les échecs de connexion, comparez l’application avec un test de connexion Universal Data Link (UDL). Utilisez le même ordinateur, fournisseur, architecture de processus, identité d’authentification, serveur, base de données et paramètres de chiffrement. Un test réussi avec un autre fournisseur ou identité ne prouve pas que la configuration de l’application fonctionne.

Enregistrement et architecture des fournisseurs

Des erreurs telles que Provider ne peuvent pas être trouvées ou REGDB_E_CLASSNOTREG (0x80040154, Class not registered) indiquent le chargement du fournisseur avant l’authentification SQL Server.

Vérifiez le fournisseur demandé par l’application. MSOLEDBSQL19 et MSOLEDBSQL identifient différentes versions majeures. Installer le pilote actuel ne change pas la sélection du fournisseur d’une application. Suivez les étapes de migration si l’application demande toujours un autre fournisseur.
Vérifiez l’architecture du processus qui héberge l’application. Une application 32 bits a besoin du fournisseur 32 bits, même sur Windows 64 bits. Pour un service ou un travail planifié, vérifiez l’exécutable et le compte utilisés par cet hôte, pas seulement votre environnement de développement.
Installez ou réparez le pilote avec l’installateur supporté sur l’ordinateur qui exécute l’application. L’installateur x64 inclut à la fois des binaires de pilotes 64 bits et 32 bits. Vérifiez les dépendances requises dans Installer le pilote OLE DB et les exigences système. Ne copiez pas les bibliothèques de pilotes d’un autre ordinateur en remplacement de l’installation.
Répétez le test UDL avec l’architecture et le fournisseur correspondants. Si ça fonctionne mais que l’application ne peut toujours pas charger le fournisseur, comparez la sélection effective du fournisseur et l’architecture de l’hôte avec le test.

Si l’erreur mentionne spécifiquement adal.dll, vérifiez le problème connu de la bibliothèque d’authentification au lieu de la traiter comme un fournisseur SQL Server manquant.

Distinguez un refus de connexion serveur d’un échec à obtenir des identifiants ou à établir une connexion chiffrée. Lisez le texte complet de l’erreur, y compris toute erreur du fournisseur imbriquée.

Pour l’erreur SQL Server 18456, demandez à l’administrateur de la base de données d’inspecter l’entrée et l’état correspondants du journal d’erreur du serveur. Vérifiez le mode d’authentification, le statut de connexion, la base de données demandée et l’accès à la base de données en utilisant MSSQLSERVER_18456. Ne supposez pas que chaque refus de connexion signifie un mot de passe incorrect.
Pour une authentification intégrée, confirmez l’identité sous laquelle l’application fonctionne. Un compte de service ou un compte de tâche planifiée peut différer de l’utilisateur qui a réussi à tester la connexion. Si le message inclut Impossible de générer le contexte SSPI, suivez le dépannage de l’interface de support de sécurité (SSPI) et le support du nom principal de service (SPN).
Pour Microsoft Entra ID, vérifiez que la méthode d'authentification sélectionnée correspond à l'environnement d'exécution de l'application et que son identité a accès à la base de données cible. Examinez les paramètres spécifiques à la méthode et les restrictions des jetons d’accès dans Use Microsoft Entra ID. Ne combinez pas un jeton d’accès avec des propriétés d’authentification ou d’identifiants conflictuelles.
Comparez les paramètres effectifs avec le tableau correct des mots-clés de la chaîne de connexion. IDBInitialize::Initialize, IDataInitialize::GetDataSource, et les objets de données ActiveX (ADO) utilisent des tables de mots-clés différentes. Consultez la table pour l’interface utilisée par votre application.

Le texte Le nom principal cible est incorrect peut apparaître dans différents contextes. Si ce message accompagne Impossible de générer un contexte SSPI, examinez l’authentification Windows et les SPN. Si l’erreur identifie le certificat ou la poignée de main de chiffrement, utilisez la section suivante.

Défaillances des certificats TLS

Des erreurs de sécurité de la couche de transport (TLS) peuvent survenir avant qu’une connexion n’atteigne SQL Server. Le pilote actuel active le chiffrement obligatoire par défaut, donc une mise à jour peut révéler un problème de confiance ou de nom de certificat qu’une ancienne configuration de connexion n’a pas détecté.

Pour la chaîne de certificats émise par une autorité non fiable, vérifiez le certificat présenté par SQL Server et la chaîne de certificats émettrice en laquelle l’ordinateur client fait confiance. Configurez un certificat serveur valide et installez les certificats root et intermédiaires de confiance requis via le processus de gestion des certificats de votre organisation.
En cas de non-correspondance entre le nom du certificat, comparez le nom du serveur ou de l’écouteur utilisé par l’application avec les noms figurant dans le certificat. Utilisez un certificat qui couvre le nom de connexion prévu. Si l’application utilise intentionnellement un nom de connexion différent, vérifiez la propriété HostNameInCertificate documentée avant de configurer le nom de certificat attendu.
Vérifiez les paramètres de chiffrement et de validation efficaces, y compris les réglages du registre. Examinez les tables de chiffrement et de validation des certificats pour vérifier la priorité et Strict le comportement. En Strict mode, le pilote valide le certificat quel que soit le réglage trust-server-certificate.
Si l’échec a commencé pendant la migration, consultez la section de dépannage relative aux versions majeures, y compris le type de valeur de la propriété de chiffrement et la restriction concernant l’utilisation de ServerCertificate en dehors du mode Strict.

Utilisez Exigences relatives aux certificats pour SQL Server et Dépannage d’une chaîne de certificats non approuvée pour des vérifications détaillées. Gardez le chiffrement et la validation des certificats activés en production. Désactiver l’un ou l’autre ne résout pas un problème de déploiement de certificats.

Échecs de la découverte du réseau et des instances

Pour le serveur non trouvé, les erreurs de localisation du serveur/instance spécifiées, ou les erreurs de refus de connexion, identifiez le point de terminaison que l’application tente d’atteindre.

Vérifiez le nom du serveur, le nom de l’instance et le port d’écoute configuré auprès de l’administrateur de la base de données. Confirmez que le service de base de données fonctionne et que le protocole et l’écouteur prévus sont activés. Ne supposez pas que chaque instance écoute sur le port 1433.
Pour une connexion TCP distante, testez le point de terminaison connu à l’aide du format de nom de serveur du pilote tcp:<server>,<port>. Gardez les mêmes paramètres d’authentification, de base de données et de chiffrement. Consultez les mots-clés de chaîne de connexion pour le mot-clé de serveur qui s’applique à votre interface.
Si l'hôte explicite et le port fonctionnent mais que l'instance nommée ne fonctionne pas, il faut enquêter sur SQL Server Browser et la découverte d'instances. Vérifiez le service du navigateur et le chemin du port 1434 du protocole de datagramme utilisateur (UDP) où la découverte du navigateur est utilisée.
Si le point de terminaison explicite échoue également, vérifiez la résolution DNS, le routage et l’accès via le pare-feu au port d’écoute réel depuis l’hôte de l’application. Suivez les erreurs de connexion liées au réseau ou spécifiques à chaque instance plutôt que de modifier plusieurs paramètres de connexion en même temps.

Pour un écouteur de groupe de disponibilité, consultez également la prise en charge de la haute disponibilité et de la reprise d’activité après sinistre. Pour LocalDB, utilisez le support LocalDB pour vérifier l’instance locale et le contexte utilisateur au lieu d’appliquer des étapes de découverte TCP à distance.

Erreurs de paramètres et de conversion de données

Si la connexion s’ouvre mais que l’exécution de commande ou la récupération des données échoue, réduisez la reproduction à la commande et à la valeur défaillantes. Conservez le type de données d’origine, la longueur, le statut nul et l’encodage des caractères lors du remplacement des données sensibles.

Comparez chaque ? marqueur de paramètre avec son ordinal de liaison, sa direction et ses métadonnées. Lorsque vous utilisez ICommandWithParameters::SetParameterInfo, associez le type de source SQL à la commande ou à la procédure stockée. Ne supposez pas que les métadonnées des paramètres soient toujours dérivées automatiquement. Examinez les paramètres de commande pour les restrictions de dérivation et le comportement des paramètres de sortie.
Inspectez les états de liaison des accesseurs ainsi que l’état et la longueur de chacune des valeurs renvoyées, et pas seulement le HRESULT dans son ensemble. Pour les échecs de définition de propriété, inspectez le dwStatus de chaque propriété. Un retour à succès partiel tel que DB_S_ERRORSOCCURRED peut nécessiter une inspection du tableau d’état même lorsqu’aucun objet d’erreur n’est disponible. Voir Codes de retour.
Pour la conversion ou la troncature, comparez le type et la taille du tampon consommateur avec les métadonnées réelles de la colonne ou du paramètre. Vérifiez la précision et l’échelle des valeurs numériques, les plages valides et les fractions de seconde pour les valeurs de date/heure, ainsi que la longueur en octets des tampons de caractères. Faites des recherches DBSTATUS_E_CANTCONVERTVALUE, et ne traitez DBSTATUS_S_TRUNCATED pas comme une valeur complète. Utilisez la correspondance des types de données, la récupération des lignes, ainsi que les conversions de date et d’heure pour les règles applicables.
Si des paramètres de sortie liés semblent manquants, épuisez les lignes retournées avant de les lire. Suivez Utilisez IMultipleResults pour traiter plusieurs ensembles de résultats. Pour les paramètres de sortie diffusés, consommez ou libérez les flux en attente avant de demander le résultat suivant, comme décrit dans le support du streaming pour les paramètres de sortie.

Pour les mappages spécifiques à ADO, consultez Utiliser ADO avec le pilote OLE DB ainsi que les restrictions d’authentification sur DataTypeCompatibility dans Utiliser Microsoft Entra ID. N’ajoutez pas de paramètre de compatibilité sans cocher les deux.

Pour les chaînes étroites corrompues dans une colonne sql_variant après une mise à jour du pilote, examinez le problème connu et la procédure de récupération existants de SSVARIANT avant de modifier les données stockées.

Pertes de connexion et délais d’attente

Notez quand la connexion a fonctionné pour la dernière fois, quelle opération a échoué, et combien de temps cette opération a duré. Distinguez ces cas avant de modifier les paramètres de réessai ou de timeout.

Phase de défaillance	Vérifications et conseils détaillés
Ouverture d’une connexion.	Inspectez d’abord les erreurs de fournisseur, réseau, authentification et TLS. Vérifiez le `DBPROP_INIT_TIMEOUT` effectif ou le mot-clé de connexion correspondant. Voir Dépannage du temps d’attente de connexion.
Exécution d’une commande.	Vérifiez `DBPROP_COMMANDTIMEOUT` ou le paramètre de délai d’expiration de la commande de l’application. Analysez les problèmes de blocage et les performances des requêtes avec la résolution des problèmes de délai d’expiration des requêtes. Augmenter le délai d’attente de connexion ne change pas le délai d’attente de commande.
Réutilisation d’une connexion inactive.	Vérifiez les conditions de récupération, les paramètres de réévaluation et les erreurs attendues dans la résilience de la connexion inactive. La récupération peut échouer lorsque le délai d’expiration de la commande expire avant la fin de la reconnexion.
Perte de connexion lors de l’exécution ou de la validation.	Mettez en corrélation les événements du client et du serveur pour vérifier s’il y a eu une interruption du réseau, un redémarrage du serveur ou un basculement. Établissez le résultat de l’opération avant de décider s’il est sûr de réessayer.

La résilience des connexions inactives ne permet pas de retentatives initiales ni de répétition automatique de commandes et transactions arbitraires. Pour une défaillance transitoire confirmée, utilisez des réessais d’application bornés avec un délai, et enregistrez chaque tentative. Ne réessayez pas à plusieurs reprises les erreurs de chargement du fournisseur, les identifiants rejetés ou les échecs de validation des certificats sans en corriger la cause.

Avertissement

Si une connexion tombe lors d’une écriture ou d’un commit, le client peut ne pas savoir si SQL Server a validé la transaction. Ne rejouez pas l’opération à l’aveugle. Vérifiez son résultat ou utilisez une application conçue pour empêcher les effets en double avant de réessayer.

Diagnostic et traçage

Collectez des diagnostics au point de défaillance, avant que des appels fournisseurs non liés ne remplacent les informations d’erreur.

Capturez l’opération défaillante, l’horodatage et le fuseau horaire, le temps écoulé, et HRESULT. Pour les utilisateurs natifs d’OLE DB, récupérez tous les enregistrements disponibles via IErrorInfo et IErrorRecords, et pas seulement la première description. Inclure SQLSTATE et le numéro d’erreur natif de SQL Server lorsque disponible via ISQLErrorInfo. Voir Récupérer les informations d’erreur et le détail des erreurs SQL Server. Pour ADO, capturez la collection Errors de la connexion.
Collectez les états par propriété, par liaison et par valeur pour les méthodes qui signalent les erreurs ainsi. Un objet d’erreur absent ne rend pas un résultat à succès partiel sûr à ignorer.
Corrélez la défaillance du client avec le journal d’erreurs serveur ou les événements étendus. Lorsque disponible, enregistrez ClientConnectionID et ActivityID. Une défaillance avant la préconnexion peut survenir sans identifiant de connexion client.
Si les enregistrements d’erreurs ne suffisent pas, utilisez Accéder aux informations de diagnostic dans le journal Extended Events pour le suivi du pilote et la configuration de la corrélation. Collectez une trace bornée autour de la reproduction et arrêtez de tracer ensuite.

Lorsque vous escaladez, incluez la version du pilote, le fournisseur demandé, l’architecture de l’application et des processus, la version serveur, la méthode d’authentification, les paramètres de connexion efficaces, le stade de défaillance, les enregistrements d’erreur et une reproduction minimale. Indiquer si le test UDL correspondant réussit et si le problème affecte un ou plusieurs hôtes.

Supprimez les mots de passe, jetons d’accès et autres secrets des paramètres de connexion et des journaux. Examinez les traces pour le texte de requête et les données sensibles, stockez-les avec un accès restreint, et partagez-les uniquement via un canal de support approuvé.

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-09-23