Ich habe einen .mdf
verwendet, um eine Verbindung zu database
und entityClient
herzustellen. Jetzt möchte ich die Verbindungszeichenfolge so ändern, dass es keine .mdf
-Datei gibt.
Ist das folgende connectionString
korrekt?
<connectionStrings>
<!--<add name="conString" connectionString="metadata=res://*/conString.csdl|res://*/conString.ssdl|res://*/conString.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.\SQL2008;AttachDbFilename=|DataDirectory|\NData.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True"" 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="Data Source=.\SQL2008;Initial Catalog=NData;Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
Weil ich immer den Fehler bekomme:
Der zugrunde liegende Anbieter ist beim Öffnen fehlgeschlagen
Ich hatte diesen Fehler und fand ein paar Lösungen:
Wenn Sie Ihre Verbindungszeichenfolge betrachten, sieht sie gültig aus. Ich fand diesen Blog-Beitrag , das Problem hier ist, dass sie integrierte Sicherheit verwendeten. Wenn Sie mit IIS arbeiten, benötigt Ihr Benutzer IIS Zugriff auf die Datenbank.
Wenn Sie Entity Frameworkmit Transaktionen verwenden, öffnet und schließt Entity Framework bei jedem Datenbankaufruf automatisch eine Verbindung. Wenn Sie also Transaktionen verwenden, versuchen Sie, eine Transaktion auf mehrere Verbindungen zu verteilen. Dies erhöht sich zu MSDTC .
( Weitere Informationen finden Sie in dieser Referenz. )
Das Ändern meines Codes in den folgenden Code hat das Problem behoben:
using (DatabaseEntities context = new DatabaseEntities())
{
context.Connection.Open();
// the rest
}
context.Connection.Open()
hat nicht geholfen, mein Problem zu lösen, also habe ich versucht, "Allow Remote Clients" in der DTC-Konfiguration zu aktivieren, kein Fehler mehr.
In Windows 7 können Sie die DTC-Konfiguration öffnen, indem Sie dcomcnfg, Komponentendienste -> Computer -> Arbeitsplatz -> Koordinator für verteilte Transaktionen -> Rechtsklick auf Lokaler DTC -> Sicherheit ausführen.
Sie sollten innerException sehen, um zu sehen, was die innere Ursache für das Auslösen eines Fehlers ist.
In meinem Fall war der ursprüngliche Fehler:
Die physische Datei "D:\Projects2\xCU\xCU\App_Data\xCUData_log.ldf" kann nicht geöffnet werden. Betriebssystemfehler 5: "5 (Zugriff verweigert.)". Ein Versuch, eine Datenbank mit automatischem Namen für die Datei D:\Projects2\xCU\xCU\App_Data\xCUData.mdf anzuhängen, ist fehlgeschlagen. Es ist eine Datenbank mit demselben Namen vorhanden, oder die angegebene Datei kann nicht geöffnet werden, oder sie befindet sich auf einer UNC-Freigabe.
dies wurde behoben, indem dem aktuellen Benutzer die vollständige Berechtigung für den Zugriff auf zugehörige mdf
und ldf
Dateien unter Verwendung der Dateieigenschaften erteilt wurde.
Ich fand das Problem, dass ich den Serverpfad innerhalb der Verbindungszeichenfolge in einer der folgenden Varianten hatte:
SERVER\SQLEXPRESS
SERVER
Wann sollte ich eigentlich haben:
.\SQLEXPRESS
Aus irgendeinem Grund bekam ich den Fehler, wenn die SQL-Instanz nicht gefunden werden konnte.
Dies ist nur ein häufiges Problem. Auch ich habe dieses Problem konfrontiert. Auf dem mit Windows-Authentifizierung konfigurierten Entwicklungscomputer funktioniert Folgendes einwandfrei:
<add name="ShoppingCartAdminEntities" connectionString="metadata=res://*/ShoppingCartAPIModel.csdl|res://*/ShoppingCartAPIModel.ssdl|res://*/ShoppingCartAPIModel.msl;provider=System.Data.SqlClient;provider connection string="data source=.\SQlExpress;initial catalog=ShoppingCartAdmin;Integrated Security=True;multipleactiveresultsets=True;application name=EntityFramework"" providerName="System.Data.EntityClient" />
Nachdem ich in IIS mit derselben Konfiguration gehostet wurde, erhalte ich den folgenden Fehler:
Der zugrunde liegende Anbieter ist beim Öffnen fehlgeschlagen
Es wurde behoben, indem connectionString
in der Konfigurationsdatei geändert wurde:
<add name="MyEntities" connectionString="metadata=res://*/ShoppingCartAPIModel.csdl|res://*/ShoppingCartAPIModel.ssdl|res://*/ShoppingCartAPIModel.msl;provider=System.Data.SqlClient;provider connection string="data source=MACHINE_Name\SQlExpress;initial catalog=ShoppingCartAdmin;persist security info=True;user id=sa;password=notmyrealpassword;multipleactiveresultsets=True;application name=EntityFramework"" providerName="System.Data.EntityClient" />
Andere häufige Fehler könnten sein:
Wenn Sie diese Ausnahmebedingung erhalten, müssen Sie die Details erweitern und die innere Ausnahme -Details anzeigen, da sie Details zu warum der fehlgeschlagenen Anmeldung enthalten. In meinem Fall enthielt die Verbindungszeichenfolge einen Benutzer, der keinen Zugriff auf meine Datenbank hatte.
Unabhängig davon, ob Sie Integrated Security (den Kontext des angemeldeten Windows-Benutzers) oder ein einzelnes SQL-Konto verwenden, stellen Sie sicher, dass der Benutzer unter "Sicherheit" über den richtigen Zugriff für die Datenbank verfügt, auf die Sie zugreifen möchten, um dieses Problem zu vermeiden.
Ich hatte ein ähnliches Problem mit SQL Server Express Edition auf Windows Server 20 . Ich habe den Netzwerkdienst einfach als Benutzer zur Datenbanksicherheit hinzugefügt.
Der SQL Server Express-Dienst wurde nicht so eingestellt, dass er automatisch startet.
1) Gehen Sie zur Systemsteuerung. 2) Verwaltung. 3) Dienst. 4) Legen Sie fest, dass SQL Server Express automatisch gestartet wird, indem Sie darauf klicken. 5) Klicken Sie mit der rechten Maustaste und starten Sie den Dienst
Ich hoffe das wird helfen.
Dies kann auch passieren, wenn Sie eine Datenbank wiederherstellen und der Benutzer bereits mit einem anderen Schema vorhanden ist, sodass Sie nicht die richtigen Berechtigungen zuweisen können.
So korrigieren Sie diesen Lauf:
USE your_database
EXEC sp_change_users_login 'Auto_Fix', 'user', NULL, 'cf'
GO
EXEC sp_change_users_login 'update_one', 'user', 'user'
GO
Stellen Sie sicher, dass jeder Elementwert in der angegebenen Verbindungszeichenfolge korrekt ist. In meinem Fall wurde derselbe Fehler angezeigt, weil der Name des in der Verbindungszeichenfolge angegebenen Katalogs (Datenbankname) falsch war.
Ich habe hier ein ähnliches Problem veröffentlicht, das mit einer auf Amazon RDS gehosteten SQL 2012-Datenbank funktioniert. Das Problem lag in der Verbindungszeichenfolge - ich hatte "Anwendungsname" und "App" Eigenschaften drin. Sobald ich diese entfernt hatte, funktionierte es.
Entity Framework 5 und Amazon RDS - "Der zugrunde liegende Anbieter ist beim Öffnen fehlgeschlagen."
Ich habe dieses Problem behoben, indem ich IIS zurückgesetzt habe, aber immer noch Integrated Authentication
in der Verbindungszeichenfolge verwendet habe.
Wenn dieser Fehler in einer ASP.NET-Webanwendung auftritt, überprüfen Sie zusätzlich zu den oben genannten Punkten Folgendes:
Das Definieren einer neuen Windows-Firewall -Regel für SQL Server (und für Port 1433) auf dem Server-Computer behebt diesen Fehler (wenn Ihr Servername, Benutzeranmeldename oder Kennwort in nicht falsch ist) Ihre Verbindungszeichenfolge ...).
Ich hatte ein ähnliches Problem mit Ausnahmen aufgrund des Verbindungsstatus. Dann stellte ich fest, dass meine Domain-Service-Klassenvariable (aus Versehen) als statisch markiert war.
Ich vermute, dass nach dem Laden der Dienstbibliothek in den Speicher jeder neue Aufruf denselben statischen Variablenwert verwendet (Domänendienstinstanz), was zu Konflikten über den Verbindungsstatus führt.
Ich denke auch, dass jeder Client-Aufruf zu einem neuen Thread führte, so dass mehrere Threads, die auf dieselbe Domain-Service-Instanz zugreifen, einem Zugunglück gleichkamen.
Ich hatte einen ähnlichen Fehler mit der inneren Ausnahme wie unten:
vorgang ist für den Status der Transaktion nicht gültig
Ich könnte das Problem beheben, indem ich die DTC-Sicherheitseinstellungen aktiviere.
Gehen Sie zu DTC-Eigenschaften, und überprüfen Sie auf der Registerkarte Sicherheit Folgendes
Ich hatte vor ein paar Tagen das gleiche Problem mit "Integrated Security = True;" In der Verbindungszeichenfolge müssen Sie die Anwendungspoolidentität unter "localsystem" ausführen. Sicher, dies wird nicht empfohlen, aber zum Testen erledigt es die Aufgabe.
So können Sie die Identität in IIS 7 ändern: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Ich habe die Datenbankdateien (.mdf/.ldf) in den Ordner App_Data kopiert, um diese Ausnahme zu beseitigen.
Ich habe im ganzen Web nach diesem Problem gesucht. Ich hatte den falschen Namen in der Verbindungszeichenfolge. Bitte überprüfen Sie die Verbindungszeichenfolge in der Datei web.config. Ich hatte name="AppTest"
, aber es hätte name="App"
sein sollen.
In meiner AppTestContext.cs-Datei hatte ich:
public AppTestContext() : this("App") { }
Falsche Verbindungszeichenfolge:
<add connectionString="Data Source=127.0.0.1;Initial Catalog=AppTest;Integrated Security=SSPI;MultipleActiveResultSets=True" name="AppTest" providerName="System.Data.SqlClient" />
Richtige Verbindungszeichenfolge:
<add connectionString="Data Source=127.0.0.1;Initial Catalog=AppTest;Integrated Security=SSPI;MultipleActiveResultSets=True" name="App" providerName="System.Data.SqlClient" />
Ich war auch mit dem gleichen Problem konfrontiert. Jetzt habe ich den Benutzernamen und das Kennwort aus der Verbindungszeichenfolge entfernt.
Dieser Fehler ist auch aufgetreten, wenn der Name der SQL Server-Instanz nicht angegeben wurde und auf dem SQL-Host mehrere SQL-Instanzen installiert sind. Hier einige Beispiele zur Verdeutlichung:
Die folgende Verbindungszeichenfolge führt zu der Ausnahme "Der zugrunde liegende Anbieter ist beim Öffnen fehlgeschlagen" ohne innere Ausnahme in einer .NET WebForms-App:
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"
Die folgende Verbindungszeichenfolge wird wie erwartet in einer .NET-WebForms-App ausgeführt, in der die SQL-Umgebung über mehrere Instanzen verfügt. Selten, ich weiß, aber ich habe ein paar verschiedene SQL-Instanzen auf meiner Entwicklungsbox, um verschiedene Projekte zu unterstützen:
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"
Für mich war es nur ein einfacher Fehler:
Ich habe Amazon EC2 verwendet und meine elastische IP-Adresse in der Verbindungszeichenfolge verwendet, aber als ich die IP-Adressen geändert habe, habe ich vergessen, meine Verbindungszeichenfolge zu aktualisieren.
In IIS legen Sie App Pool Identity als Service Account-Benutzer oder Administrator-Account oder als Ant-Account fest, der die Berechtigung hat, die Operation in dieser Datenbank auszuführen.
Ich hatte dieses Problem, weil sich das Login für den Anwendungspool, unter dem diese App ausgeführt wurde, geändert hat.
In IIS:
Suchen Sie den Anwendungspool, indem Sie auf Ihre Site klicken und zu den Grundeinstellungen wechseln.
Wechseln Sie zu Anwendungspools.
Klicken Sie auf den Anwendungspool Ihrer Site.
Klicken Sie auf Erweiterte Einstellungen.
Geben Sie unter Identität den Account-Benutzernamen und das Passwort ein.
Starten Sie Ihre Site neu und versuchen Sie es erneut.
Ich hatte ein ähnliches Problem: In meinen Testfällen bekam ich immer diesen Fehler. Ich habe festgestellt, dass mein "Distributed Transaction Service" nicht gestartet wurde (run: services.msc -> start "Distributed Transaction Service" (am besten so einstellen, dass er automatisch startet)). Nachdem ich das getan habe, hat es wie ein Zauber funktioniert ...
KEINE der Antworten hat bei mir funktioniert
Ich denke, dass einige von uns alle dumme Fehler machen, es gibt 100 Möglichkeiten, um zu scheitern ...
Mein Problem war ein neues Projekt, ich habe die gesamte Konfiguration in einem anderen Projekt eingerichtet, aber der Aufrufer war ein Web-API-Projekt, in das ich dieselbe Verbindungszeichenfolge im Web-API-Projekt kopieren musste.
Ich denke, das ist verrückt, wenn man bedenkt, dass ich nicht einmal dbcontext oder irgendetwas aus der Web-API aktualisiert habe.
Andernfalls hat die Klassenbibliothek versucht, nach einer Datenbank mit dem Namen zu suchen
TokenApi.Core.CalContext
mein Projekt heißt TokenApi.Core
und CalContext
ist der Name der Verbindungszeichenfolge und des Dateinamens
Ein häufiger Fehler, den ich gemacht habe, weil ich eine Anwendung von einem PC auf einen anderen verschoben habe und keiner der oben genannten Fehler aufgetreten ist, war, dass ich vergessen habe, die Verbindungszeichenfolge sowohl in App.Config als auch in Web.Config zu kopieren!
In meinem Fall stimmte der Name der Verbindungszeichenfolge, die ich im Kontextkonstruktor registrierte, nicht mit dem Namen in meiner web.config überein. Einfacher Fehler durch Kopieren und Einfügen: D
public DataContext()
: base(nameOrConnectionString: "ConnStringName")
{
Database.SetInitializer<DataContext>(null);
}
Ich hatte das gleiche Problem, aber was bei mir funktionierte, war das Entfernen dieser aus der Verbindungszeichenfolge:
persist security info=True
Ich hatte diesen Fehler plötzlich aus heiterem Himmel auf einer unserer Websites. In meinem Fall stellte sich heraus, dass das Passwort des SQL-Benutzers abgelaufen war! Deaktivieren Sie das Feld für den Kennwortablauf in SQL Server Management Studio .
Ich habe nur ein Passwort in meine web.config-Verbindungszeichenfolge eingefügt, das bei mir funktioniert hat.
<add name="Test2016Entities" connectionString="metadata=res://*/Models.PersonDataContext.csdl|res://*/Models.PersonDataContext.ssdl|res://*/Models.PersonDataContext.msl;provider=System.Data.SqlClient;provider connection string="data source=KEDAR-PC;initial catalog=Test2016;user id=sa;password=mypc123;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
Hallo, wenn Sie eine Kontextklasse verwenden, können Sie den folgenden Code verwenden:
using (ClassContext context = new ClassContext()){
((IObjectContextAdapter)context).ObjectContext.Connection.Open();
//SOMETHING TO DO......
((IObjectContextAdapter)context).ObjectContext.Connection.Close();
}
in meinem Fall wurde die Serveradresse vom Serveradministrator geändert, sodass die Verbindungszeichenfolge in eine neue Serveradresse geändert werden musste
Ich habe diesen Weg gelöst.
Schritt 1: Öffnen Sie den Internetinformationsdienst-Manager
Schritt 2: Klicken Sie im linken Navigationsbaum auf Anwendungspools.
Schritt 3: Wählen Sie Ihren Versionspool aus. In meinem Fall verwende ich ASP .Net v4.0. Wenn Sie diese Version nicht haben, wählen Sie DefaultAppPool.
Schritt 4: Klicken Sie mit der rechten Maustaste auf Schritt 3 und wählen Sie erweiterte Einstellungen.
Schritt 5: Wählen Sie Identität im Eigenschaftenfenster und klicken Sie auf die Schaltfläche, um den Wert zu ändern.
Schritt 6: Wählen Sie im Kombinationsfeld "Integrierte Konten" die Option "Lokales System" und klicken Sie auf "OK". Das ist es. Führen Sie jetzt Ihre Anwendung aus. Alles funktioniert gut.
CodeProject-Lösung: Der zugrunde liegende Anbieter schlug beim Öffnen fehl
Fügen Sie diese integrierte Sicherheit hinzu = True;
und es sollte funktionieren .. Ich füge dies zu meiner Konfiguration hinzu und es beginnt zu funktionieren.
ich habe den gleichen Fehler, den ich gefunden habe, als ich meine Verbindungszeichenfolge in eine neue Datenquelle ändere. Ich vergesse, den Benutzernamen und das Kennwort für die neue Datenbank zu ändern