Les requêtes de serveur lié qui utilisent MSDASQL échouent en raison de l’erreur 7416.

S’applique à :

  • mises à jour de SQL Server 2025 CU et GDR depuis avril 2026
  • mises à jour de SQL Server 2022 CU et GDR depuis mars 2026
  • mises à jour de SQL Server 2019 CU et GDR depuis avril 2026
  • mises à jour de SQL Server 2017 CU et GDR depuis avril 2026
  • Mises à jour GDR de SQL Server 2016 SP3 et d’Azure Connect Pack depuis avril 2026
  • Azure SQL Managed Instance (Instance gérée Azure SQL)

Résumé

Cet article décrit un problème connu dans lequel les requêtes de serveur lié qui utilisent le MSDASQL fournisseur (fournisseur OLE DB pour pilotes ODBC) et spécifient une chaîne de fournisseur échouent et génèrent l’erreur 7416. L’article fournit également des solutions de contournement qui restaurent la connectivité du serveur lié sans restaurer la mise à jour.

Symptoms

Les requêtes de serveur lié qui utilisent le MSDASQL fournisseur et spécifient une chaîne de fournisseur (@provstr) échouent et retournent le message d’erreur suivant lorsqu’un utilisateur qui n’est pas membre du rôle serveur fixe sysadmin exécute la requête :

Msg 7416, niveau 16
L'accès au serveur distant est refusé parce qu'il n'y a pas de mappage des connexions.

L’échec peut se produire même si le serveur lié et les mappages de connexion sont configurés correctement.

Cause

Un contrôle de validation de connexion plus strict dans l’Moteur de base de données peut rejeter les connexions pour certaines configurations de serveur lié qui utilisent le fournisseur MSDASQL, même si des builds antérieures ont autorisé ces connexions.

Solution temporaire

Pour contourner ce problème sans restaurer la mise à jour, utilisez l’une des méthodes suivantes :

  • Si votre configuration ne nécessite pas la chaîne de fournisseur (@provstr), supprimez-la de la définition du serveur lié.
  • Ajoutez une entrée User ID à la chaîne du fournisseur (@provstr). Par exemple, définissez User ID=<value>. La chaîne de fournisseur doit toujours également inclure UID .

Vous pouvez également empêcher l’échec en accordant des autorisations sysadmin à l’utilisateur concerné. Toutefois, nous vous déconseillons d’utiliser cette méthode.

Contenu connexe

  • Last updated on