Erreur MSSQL «Le fournisseur sous-jacent a échoué à l'ouverture»

J'utilisais un .mdfpour me connecter à un databaseet entityClient. Maintenant, je veux changer la chaîne de connexion pour qu'il n'y ait pas de .mdffichier.

Est-ce que ce qui suit est connectionStringcorrect?

<connectionStrings>
   <!--<add name="conString" connectionString="metadata=res://*/conString.csdl|res://*/conString.ssdl|res://*/conString.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\SQL2008;AttachDbFilename=|DataDirectory|\NData.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />-->
   <add name="conString" connectionString="metadata=res://*/conString.csdl|res://*/conString.ssdl|res://*/conString.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.\SQL2008;Initial Catalog=NData;Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />

Parce que je reçois toujours l'erreur:

Le fournisseur sous-jacent a échoué sur Open

J'ai eu cette erreur et j'ai trouvé quelques solutions:

En regardant votre chaîne de connexion, elle semble valide. J'ai trouvé ce billet de blog , le problème ici est qu'ils utilisaient Integrated Security . Si vous exécutez sur IIS, votre utilisateur IIS doit avoir accès à la base de données.

Si vous utilisez Entity Framework avec des transactions , Entity Framework ouvre et ferme automatiquement une connexion avec chaque appel de base de données. Ainsi, lorsque vous utilisez des transactions, vous essayez de répartir une transaction sur plusieurs connexions. Cela élève à MSDTC .

( Voir cette référence pour plus d'informations. )

Changer mon code comme suit l'a corrigé:

using (DatabaseEntities context = new DatabaseEntities())
{
    context.Connection.Open();
    // the rest
}

context.Connection.Open() n'a pas aidé à résoudre mon problème, j'ai donc essayé d'activer "Autoriser les clients distants" dans la configuration DTC, plus d'erreur.

Dans Windows 7, vous pouvez ouvrir la configuration DTC en exécutant dcomcnfg, Services de composants -> Ordinateurs -> Poste de travail -> Coordinateur de transactions distribuées -> Cliquez avec le bouton droit sur Local DTC -> Sécurité.

Vous devriez voir innerException pour voir quelle est la cause interne du lancement de l'erreur.

Dans mon cas, l'erreur d'origine était:

Impossible d'ouvrir le fichier physique "D: \ Projects2 \ xCU \ xCU \ App_Data \ xCUData_log.ldf". Erreur 5 du système d'exploitation: "5 (l'accès est refusé.)". Une tentative pour joindre une base de données nommée automatiquement pour le fichier D: \ Projects2 \ xCU \ xCU \ App_Data \ xCUData.mdf a échoué. Une base de données portant le même nom existe, ou le fichier spécifié ne peut pas être ouvert, ou il se trouve sur le partage UNC.

qui a résolu en donnant la permission complète à l'utilisateur actuel d'accéder aux fichiers liés mdfet ldfen utilisant les propriétés des fichiers.

J'ai trouvé que le problème était que j'avais le chemin du serveur dans la chaîne de connexion dans l'une de ces variantes:

SERVER\SQLEXPRESS
SERVER

Quand j'aurais vraiment dû:

.\SQLEXPRESS

Pour une raison quelconque, j'ai eu l'erreur chaque fois qu'il avait du mal à localiser l'instance de SQL.

Il s'agit uniquement d'un problème courant. Même moi, j'ai fait face à ce problème. Sur la machine de développement, configurée avec l'authentification Windows, cela fonctionne parfaitement:

<add name="ShoppingCartAdminEntities" connectionString="metadata=res://*/ShoppingCartAPIModel.csdl|res://*/ShoppingCartAPIModel.ssdl|res://*/ShoppingCartAPIModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=.\SQlExpress;initial catalog=ShoppingCartAdmin;Integrated Security=True;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

Une fois hébergé dans IIS avec la même configuration, j'ai eu cette erreur:

Le fournisseur sous-jacent a échoué sur Open

Il a été résolu de changer connectionStringdans le fichier de configuration:

<add name="MyEntities" connectionString="metadata=res://*/ShoppingCartAPIModel.csdl|res://*/ShoppingCartAPIModel.ssdl|res://*/ShoppingCartAPIModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=MACHINE_Name\SQlExpress;initial catalog=ShoppingCartAdmin;persist security info=True;user id=sa;password=notmyrealpassword;multipleactiveresultsets=True;application name=EntityFramework&quot;" providerName="System.Data.EntityClient" />

D'autres erreurs courantes pourraient être:

1. Le service de base de données a pu être arrêté
2. Attributs de source de données pointant vers une base de données locale avec authentification Windows et hébergée dans IIS
3. Le nom d'utilisateur et le mot de passe peuvent être erronés.

Lorsque vous recevez cette exception, assurez-vous de développer les détails et examinez les détails de l' exception interne car ils fourniront des détails sur la raison de l'échec de la connexion. Dans mon cas, la chaîne de connexion contenait un utilisateur qui n'avait pas accès à ma base de données.

Que vous utilisiez Integrated Security (le contexte de l'utilisateur Windows connecté) ou un compte SQL individuel, assurez-vous que l'utilisateur dispose d'un accès approprié sous `` Sécurité '' pour la base de données à laquelle vous essayez d'accéder pour éviter ce problème.

J'ai eu un problème similaire avec SQL Server Express Edition sur Windows Server 2003 . J'ai simplement ajouté le service réseau en tant qu'utilisateur dans la sécurité de la base de données.

Le service SQL Server Express n'a pas été défini pour démarrer automatiquement.

1) Accédez au panneau de configuration 2) Outils d'administration 3) Service 4) Configurez SQL Server express pour qu'il démarre automatiquement en cliquant dessus 5) Faites un clic droit et démarrez le service

J'espère que cela aidera.

Cela peut également se produire si vous restaurez une base de données et que l'utilisateur existe déjà avec un schéma différent, vous empêchant d'attribuer les autorisations appropriées.

Pour corriger cette exécution:

USE your_database
EXEC sp_change_users_login 'Auto_Fix', 'user', NULL, 'cf'
GO
EXEC sp_change_users_login 'update_one', 'user', 'user'
GO

J'ai publié un problème similaire ici, en travaillant avec une base de données SQL 2012 hébergée sur Amazon RDS. Le problème était dans la chaîne de connexion - j'avais "Application Name" et "App" propriétés là-dedans. Une fois que j'ai retiré ceux-ci, cela a fonctionné.

Entity Framework 5 et Amazon RDS - "Le fournisseur sous-jacent a échoué sur Open."

Assurez-vous que chaque valeur d'élément dans la chaîne de connexion fournie est correcte. Dans mon cas, j'obtenais la même erreur car le nom du catalogue (nom de la base de données) spécifié dans la chaîne de connexion était incorrect.

J'ai eu un problème similaire avec des exceptions en raison de l'état de la connexion, puis j'ai réalisé que ma variable de classe de service de domaine était marquée comme statique (par erreur).

Je suppose qu'une fois que la bibliothèque de services est chargée en mémoire, chaque nouvel appel finit par utiliser la même valeur de variable statique (instance de service de domaine), provoquant des conflits via l'état de connexion.

Je pense également que chaque appel client a entraîné un nouveau thread, donc plusieurs threads accédant à la même instance de service de domaine équivalaient à une épave de train.

J'ai eu le même problème mais ce qui a fonctionné pour moi a été de supprimer cela de la chaîne de connexion:

persist security info=True

J'ai eu une erreur similaire avec l'exception interne comme ci-dessous:

l'opération n'est pas valide pour l'état de la transaction

Je pourrais le résoudre en activant les paramètres de sécurité DTC.

Allez dans Propriétés de DTC, sous l'onglet Sécurité, vérifiez ci-dessous

• Accès réseau DTC
• Autoriser les clients distants
• Communication du gestionnaire de transactions
• Autoriser les entrants
• Autoriser les appels sortants

Si vous obtenez cette erreur sur une application Web ASP.NET, en plus des autres éléments mentionnés, vérifiez les points suivants:

1. Autorisations de sécurité des utilisateurs de base de données (quels utilisateurs sont autorisés à accéder à votre base de données.
2. Vérifiez votre pool d'applications dans IIS et assurez-vous que c'est le bon qui est autorisé à accéder à votre base de données.

Je me suis débarrassé de cela en réinitialisant IIS , mais en l'utilisant toujours Integrated Authenticationdans la chaîne de connexion.

La définition d'une nouvelle règle de pare-feu Windows pour SQL Server (et pour le port 1433) sur la machine serveur résout cette erreur (si votre nom de serveur, nom d'utilisateur ou mot de passe n'est pas incorrect dans votre chaîne de connexion ...).

Une erreur courante que j'ai commise parce que je déplaçais une application d'un PC à un autre et rien de ce qui précède n'a fonctionné, c'est que j'ai oublié de copier la chaîne de connexion dans App.Config et Web.Config!

J'ai eu un problème similaire: dans mes exécutions de cas de test, j'ai toujours eu cette erreur. J'ai découvert que mon "service de transactions distribuées" n'était pas démarré (exécutez: services.msc -> démarrer "service de transactions distribuées" (il est préférable de le configurer pour qu'il démarre automatiquement)). Après cela, cela a fonctionné comme un charme ...

J'ai copié les fichiers de base de données (.mdf / .ldf) dans le dossier App_Data pour me débarrasser de cette exception.

J'étais également confronté au même problème. Maintenant, je l'ai fait en supprimant le nom d'utilisateur et le mot de passe de la chaîne de connexion.

Pour moi, ce n'était qu'une simple erreur:

J'ai utilisé Amazon EC2 et j'ai utilisé mon adresse IP élastique dans la chaîne de connexion, mais lorsque j'ai changé d'adresse IP, j'ai oublié de mettre à jour ma chaîne de connexion.

J'ai eu cette erreur soudainement survenue sur l'un de nos sites. Dans mon cas, il s'est avéré que le mot de passe de l'utilisateur SQL avait expiré! Décocher la case d'expiration du mot de passe dans SQL Server Management Studio a fait l'affaire!

J'ai eu le même problème il y a quelques jours, en utilisant "Integrated Security = True;" dans la chaîne de connexion, vous devez exécuter l'identité du pool d'applications sous "localsystem" Bien sûr, ce n'est pas recommandé, mais pour le tester, il fait le travail.

Voici comment vous pouvez modifier l'identité dans IIS 7: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

Dans IIS, définissez l' identité du pool d'applications en tant qu'utilisateur de compte de service ou compte d'administrateur ou compte ant qui est autorisé à effectuer l'opération sur cette base de données.

Dans mon cas, j'avais un décalage entre le nom de la chaîne de connexion que j'enregistrais dans le constructeur du contexte et le nom dans mon web.config. Erreur simple causée par le copier-coller: D

    public DataContext()
        : base(nameOrConnectionString: "ConnStringName")
    {
        Database.SetInitializer<DataContext>(null);
    }

J'ai la même erreur que j'ai trouvée lorsque je change ma connexion Chaîne vers une nouvelle source de données J'oublie de changer le nom d'utilisateur et le mot de passe pour la nouvelle base de données

J'ai également rencontré cette erreur si le nom de l'instance SQL Server n'est pas spécifié et que l'hôte SQL a plusieurs instances SQL installées. Voici quelques exemples à clarifier:

La chaîne de connexion ci-dessous entraîne l'exception «Le fournisseur sous-jacent a échoué à l'ouverture» sans exception interne dans une application .NET WebForms:

 connectionString="metadata=res://*/Entities.csdl|res://*/Entities.ssdl|res://*/Entities.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=Entities;User ID=user;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"

La chaîne de connexion suivante s'exécute comme prévu dans une application .net WebForms où l'environnement SQL a plusieurs instances. Rare, je sais, mais j'ai quelques instances SQL différentes sur ma boîte de développement pour accueillir différents projets:

 connectionString="metadata=res://*/Entities.csdl|res://*/Entities.ssdl|res://*/Entities.msl;provider=System.Data.SqlClient;provider connection string="Data Source=localhost\SQLSERVER2014;Initial Catalog=Entities;User ID=user;Password=password;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"

dans mon cas, l'adresse du serveur a été modifiée par l'administrateur du serveur, j'ai donc dû changer la chaîne de connexion en une nouvelle adresse de serveur

J'ai eu ce problème car la connexion au pool d'applications sous laquelle cette application s'exécutait avait changé.

Dans IIS:

• Trouvez le pool d'applications en cliquant sur votre site et accédez aux paramètres de base.

• Accédez aux pools d'applications.

• Cliquez sur le pool d'applications de votre site.

• Cliquez sur Paramètres avancés.

• Dans Identité, entrez le nom d'utilisateur et le mot de passe du compte.

• Redémarrez votre site et réessayez.