Błąd MSSQL „Podstawowy dostawca nie powiódł się w Open”

Użyłem .mdfdo połączenia z databasei entityClient. Teraz chcę zmienić parametry połączenia, aby nie było .mdfpliku.

Czy poniższe informacje są connectionStringprawidłowe?

<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" />

Ponieważ zawsze pojawia się błąd:

Dostawca bazowy zawiódł na Open

Miałem ten błąd i znalazłem kilka rozwiązań:

Patrząc na ciąg połączenia, wygląda na poprawny. Znalazłem ten post na blogu , problem polega na tym, że korzystali ze zintegrowanych zabezpieczeń . Jeśli korzystasz z IIS, użytkownik IIS potrzebuje dostępu do bazy danych.

Jeśli używasz Entity Framework z transakcjami , Entity Framework automatycznie otwiera i zamyka połączenie z każdym wywołaniem bazy danych. Korzystając z transakcji, próbujesz rozłożyć transakcję na wiele połączeń. To podnosi się do MSDTC .

( Zobacz to odniesienie, aby uzyskać więcej informacji. )

Zmieniłem mój kod na następujący, naprawiłem go:

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

context.Connection.Open() nie pomogło rozwiązać mojego problemu, więc próbowałem włączyć opcję „Zezwalaj klientom zdalnym” w konfiguracji DTC, nie ma więcej błędów.

W Windows 7 możesz otworzyć konfigurację DTC, uruchamiając dcomcnfg, Usługi składowe -> Komputery -> Mój komputer -> Koordynator transakcji rozproszonych -> Kliknij prawym przyciskiem myszy na Lokalny DTC -> Bezpieczeństwo.

Powinieneś zobaczyć innerException, aby zobaczyć, jaka jest wewnętrzna przyczyna błędu.

W moim przypadku pierwotny błąd to:

Nie można otworzyć pliku fizycznego „D: \ Projekty2 \ xCU \ xCU \ App_Data \ xCUData_log.ldf”. Błąd systemu operacyjnego 5: „5 (Odmowa dostępu.)”. Próba dołączenia bazy danych o nazwach automatycznych do pliku D: \ Projekty2 \ xCU \ xCU \ App_Data \ xCUData.mdf nie powiodła się. Baza danych o tej samej nazwie istnieje lub nie można otworzyć określonego pliku lub znajduje się na udziale UNC.

rozwiązane przez udzielenie pełnego pozwolenia bieżącemu użytkownikowi na dostęp do powiązanych mdfi ldfplików za pomocą właściwości plików.

Znalazłem problem polegający na tym, że miałem ścieżkę serwera w ciągu połączenia w jednym z tych wariantów:

SERVER\SQLEXPRESS
SERVER

Kiedy naprawdę powinienem mieć:

.\SQLEXPRESS

Z jakiegoś powodu pojawia się błąd, ilekroć ma on trudności ze zlokalizowaniem wystąpienia SQL.

Jest to tylko powszechny problem. Nawet ja napotkałem ten problem. Na komputerze programistycznym, skonfigurowanym z uwierzytelnianiem systemu Windows, działa idealnie:

<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" />

Raz hostowany w IIS w tej samej konfiguracji, otrzymałem ten błąd:

Dostawca bazowy zawiódł na Open

Zostało to rozwiązane poprzez zmianę connectionStringw pliku konfiguracyjnym:

<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" />

Inne typowe błędy to:

1. Usługa bazy danych może zostać zatrzymana
2. Atrybuty źródła danych wskazujące na lokalną bazę danych z uwierzytelnianiem Windows i hostowane w IIS
3. Nazwa użytkownika i hasło mogą być nieprawidłowe.

Po otrzymaniu tego wyjątku upewnij się, że rozwinąłeś szczegóły i spójrz na szczegóły wyjątku wewnętrznego, ponieważ podadzą one dlaczego niepowodzenia logowania. W moim przypadku ciąg połączenia zawierał użytkownika, który nie miał dostępu do mojej bazy danych.

Bez względu na to, czy korzystasz ze zintegrowanych zabezpieczeń (kontekst zalogowanego użytkownika Windows), czy z indywidualnego konta SQL, upewnij się, że użytkownik ma odpowiedni dostęp w „Zabezpieczeniach” do bazy danych, do której próbujesz uzyskać dostęp, aby zapobiec temu problemowi.

Miałem podobny problem z SQL Server Express Edition w systemie Windows Server 2003 . Po prostu dodałem usługę sieciową jako użytkownika do zabezpieczenia bazy danych.

Usługa SQL Server Express nie została skonfigurowana do automatycznego uruchamiania.

1) Przejdź do panelu sterowania 2) Narzędzia administracyjne 3) Usługa 4) Ustaw ekspresowe uruchamianie programu SQL Server, klikając go 5) Kliknij prawym przyciskiem myszy i uruchom usługę

Mam nadzieję, że to pomoże.

Może się to również zdarzyć, jeśli przywrócisz bazę danych, a użytkownik już istnieje z innym schematem, co uniemożliwi przypisanie poprawnych uprawnień.

Aby poprawić ten przebieg:

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

Podobny problem opublikowałem tutaj, pracując z bazą danych SQL 2012 hostowaną na Amazon RDS. Problem dotyczył ciągu połączenia - miałem tam właściwości „Nazwa aplikacji” i „Aplikacja” . Po ich usunięciu zadziałało.

Entity Framework 5 i Amazon RDS - „Bazowy dostawca poniósł porażkę w Open”.

Upewnij się, że każda wartość elementu w dostarczonym ciągu połączenia jest poprawna. W moim przypadku otrzymywałem ten sam błąd, ponieważ nazwa katalogu (nazwa bazy danych) określona w ciągu połączenia była niepoprawna.

Miałem podobny problem z wyjątkami ze względu na stan połączenia, a potem zdałem sobie sprawę, że moją zmienną klasy usługi domeny oznaczono jako statyczną (przez pomyłkę).

Domyślam się, że po załadowaniu biblioteki usług do pamięci każde nowe wywołanie kończy się przy użyciu tej samej wartości zmiennej statycznej (instancja usługi domeny), powodując konflikty przez stan połączenia.

Myślę też, że każde wywołanie klienta skutkowało nowym wątkiem, więc wiele wątków uzyskujących dostęp do tej samej instancji usługi domenowej było wrakiem pociągu.

Miałem ten sam problem, ale dla mnie zadziałało usunięcie tego z ciągu połączenia:

persist security info=True

Miałem podobny błąd z wewnętrznym wyjątkiem jak poniżej:

operacja nie jest ważna dla stanu transakcji

Mogę to rozwiązać, włączając ustawienia zabezpieczeń DTC.

Przejdź do właściwości DTC, w zakładce Bezpieczeństwo, sprawdź poniżej

• Dostęp do sieci DTC
• Zezwalaj RemoteClients
• Komunikacja menedżera transakcji
• Zezwalaj na przychodzące
• Zezwalaj na wychodzące

Jeśli ten błąd wystąpi w aplikacji sieci Web ASP.NET, oprócz innych wymienionych rzeczy sprawdź następujące elementy:

1. Uprawnienia użytkownika do bazy danych (którzy użytkownicy mają dostęp do bazy danych).
2. Sprawdź pulę aplikacji w usługach IIS i upewnij się, że jest to ta poprawna, która ma dostęp do bazy danych.

Pozbyłem się tego przez zresetowanie IIS , ale nadal używam Integrated Authenticationw ciągu połączenia.

Zdefiniowanie nowej reguły Zapory systemu Windows dla programu SQL Server (i dla portu 1433) na maszynie serwerowej rozwiązuje ten błąd (jeśli nazwa serwera, nazwa użytkownika lub hasło nie są niepoprawne w ciągu połączenia ...).

Częstym błędem, który popełniłem, ponieważ przenosiłem aplikację z jednego komputera na inny i żadne z powyższych nie działało, było to, że zapomniałem skopiować parametry połączenia do App.Config i Web.Config!

Miałem podobny problem: w moich wykonaniach przypadków testowych zawsze występował ten błąd. Dowiedziałem się, że moja „Usługa rozproszonych transakcji” nie została uruchomiona (uruchom: services.msc -> uruchom „Usługa rozproszonych transakcji” (najlepiej ustawić ją tak, aby uruchamiała się automatycznie)). Kiedy to zrobiłem, zadziałało jak urok ...

Skopiowałem pliki bazy danych (.mdf / .ldf) do folderu App_Data, aby pozbyć się tego wyjątku.

Miałem też do czynienia z tym samym problemem. Teraz zrobiłem to, usuwając nazwę użytkownika i hasło z ciągu połączenia.

Dla mnie był to prosty błąd:

Użyłem Amazon EC2 i użyłem elastycznego adresu IP w ciągu połączenia, ale kiedy zmieniłem adresy IP, zapomniałem zaktualizować ciąg połączenia.

Miałem ten błąd nagle niespodziewanie na jednej z naszych witryn. W moim przypadku okazało się, że hasło użytkownika SQL wygasło! Usunięcie zaznaczenia pola wygaśnięcia hasła w SQL Server Management Studio załatwiło sprawę !

Ten sam problem miałem kilka dni temu, używając „Integrated Security = True;” w ciągu połączenia musisz uruchomić tożsamość puli aplikacji w „systemie lokalnym”. Nie jest to zalecane, ale do testowania działa.

W ten sposób możesz zmienić tożsamość w IIS 7: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

W IIS ustaw tożsamość puli aplikacji jako konto użytkownika lub konto administratora lub konto ant, które ma uprawnienia do wykonania operacji na tej bazie danych.

W moim przypadku miałem niezgodność między nazwą ciągu połączenia, którą rejestrowałem w konstruktorze kontekstu, a nazwą w moim pliku web.config. Prosty błąd spowodowany kopiowaniem i wklejaniem: D

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

mam ten sam błąd, który znalazłem podczas zmiany połączenia Połączenie z nowym źródłem danych Zapomniałem zmienić nazwy użytkownika i hasła dla nowej bazy danych

Wystąpił również ten błąd, jeśli nazwa wystąpienia programu SQL Server nie została określona, ​​a host SQL ma zainstalowanych wiele wystąpień SQL. Oto kilka przykładów, które należy wyjaśnić:

Poniższy ciąg połączenia powoduje wyjątek „Dostawca bazowy nie powiódł się podczas otwierania” bez wewnętrznego wyjątku w aplikacji .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"

Poniższy ciąg połączenia jest wykonywany zgodnie z oczekiwaniami w aplikacji WebForms .net, w której środowisko SQL ma wiele wystąpień. Rzadko wiem, ale mam kilka różnych instancji SQL na moim urządzeniu deweloperskim, aby pomieścić różne projekty:

 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"

w moim przypadku adres serwera został zmieniony przez administratora serwera, więc musiałem zmienić parametry połączenia na nowy adres serwera

Miałem ten problem, ponieważ nazwa logowania do puli aplikacji, pod którą ta aplikacja była uruchomiona, uległa zmianie.

W IIS:

• Znajdź pulę aplikacji, klikając swoją witrynę i przechodząc do Ustawień podstawowych.

• Idź do pul aplikacji.

• Kliknij pulę aplikacji swojej witryny.

• Kliknij Ustawienia zaawansowane.

• W polu Tożsamość wprowadź login i hasło do konta.

• Uruchom ponownie witrynę i spróbuj ponownie.