Stworzyłem serwis WWW, który zapisuje pewne dane do bazy danych. Ale otrzymuję ten błąd:
Nie można otworzyć „testu” bazy danych żądanego podczas logowania. Logowanie nie powiodło się. Logowanie nie powiodło się dla użytkownika „xyz \ ASPNET”.
Moje parametry połączenia to
Data Source=.\SQLExpress;Initial Catalog=IFItest;Integrated Security=True
Odpowiedzi:
Cóż, błąd jest całkiem jasny, nie? Próbujesz połączyć się z serwerem SQL za pomocą użytkownika „xyz / ASPNET” - jest to konto, na którym działa Twoja aplikacja ASP.NET.
To konto nie może łączyć się z SQL Server - albo utwórz login na SQL Server dla tego konta, albo określ inne prawidłowe konto SQL Server w parametrach połączenia.
Czy możesz pokazać nam swoje parametry połączenia (aktualizując swoje oryginalne pytanie)?
AKTUALIZACJA: OK, używasz zintegrowanego uwierzytelniania systemu Windows -> musisz utworzyć login SQL Server dla „xyz \ ASPNET” na swoim serwerze SQL - lub zmienić parametry połączenia na coś takiego:
connectionString="Server=.\SQLExpress;Database=IFItest;User ID=xyz;pwd=top$secret"
Jeśli masz użytkownika „xyz” z hasłem „ściśle tajne” w Twojej bazie danych.
Wybrałbym drugą opcję: komunikat o błędzie sugeruje, że domyślna baza danych albo nie ma do niej dostępu, albo nie ma do niej praw, a nie jest skonfigurowana jako login.
Aby sprawdzić, czy jest skonfigurowany jako login
SELECT SUSER_ID('xyz\ASPNET') -- (**not** SUSER_SID)
Jeśli NULL
CREATE LOGIN [xyz\ASPNET] FROM WINDOWS
Jeśli nie NULL
USE test
GO
SELECT USER_ID('xyz\ASPNET')
Jeśli NULL
USE test
GO
CREATE USER [xyz\ASPNET] FROM LOGIN [xyz\ASPNET]
Najlepszym rozwiązaniem problemu z logowaniem jest utworzenie użytkownika logowania w sqlServer. Oto kroki, aby utworzyć login SQL Server, który używa uwierzytelniania systemu Windows (SQL Server Management Studio):
Na przykład, jeśli nazwa użytkownika to xyz\ASPNET, wprowadź tę nazwę w polu Nazwa logowania.
Musisz także zmienić mapowanie użytkownika, aby umożliwić dostęp do bazy danych, do której chcesz uzyskać dostęp.
W większości przypadków nie jest to problem z logowaniem, ale z tworzeniem samej bazy danych. Więc jeśli wystąpi błąd podczas tworzenia bazy danych, nie zostanie ona utworzona w pierwszej kolejności. W takim przypadku, jeśli spróbujesz się zalogować, niezależnie od użytkownika, logowanie zakończy się niepowodzeniem. Zwykle dzieje się tak z powodu logicznej błędnej interpretacji kontekstu db.
Odwiedź witrynę w przeglądarce i NAPRAWDĘ przeczytaj te dzienniki błędów, może to pomóc w wykryciu problemu z Twoim kodem (zwykle są to sprzeczne problemy logiczne z modelem).
W moim przypadku kod skompilowany dobrze, ten sam problem z logowaniem, podczas gdy nadal pobierałem studio zarządzania, przeszedłem przez dziennik błędów, naprawiłem ograniczenia kontekstu bazy danych i strona zaczęła działać poprawnie ... tymczasem studio zarządzania nadal pobiera
Dla mnie baza danych nie została utworzona, a kod EF powinien ją najpierw utworzyć, ale zawsze kończy się tym błędem. Te same parametry połączenia działały w domyślnym projekcie sieci Web ASPNET Core. Rozwiązaniem było dodanie
_dbContext.Database.EnsureCreated()
przed pierwszym kontaktem z bazą danych (przed umieszczeniem w bazie danych).
Błąd prezentuje się jako komunikat podobny do tego:
Nie można otworzyć bazy danych „DATABASE NAME” żądanej przy logowaniu. Logowanie nie powiodło się. Logowanie nie powiodło się dla użytkownika XYZ.
Rozwiązanie jest układane w następujących krokach. Nie utracisz żadnych danych w swojej bazie danych i nie powinieneś usuwać pliku bazy danych!
Wymaganie wstępne: musisz mieć zainstalowany program SQL Server Management Studio (pełny lub ekspresowy)
Źródło rozwiązania: https://www.codeproject.com/Tips/775607/How-to-fix-LocalDB-Requested-Login-failed
Dzieje się tak również, gdy wpiszesz złą nazwę DB
ex : xxx-db-dev to xxx-dev-db
Czasami to tylko głupi błąd. Potrzeba mi więcej niż 1 godziny, żeby się tego dowiedzieć :( ponieważ najpierw próbuję wielu trudnych rzeczy
To działa dla mnie.
Przeczytaj tego bloga.
Użyłem uwierzytelniania systemu Windows, aby połączyć się z plikiem .mdf lokalnej bazy danych, a moim serwerem lokalnym był serwer sql 2014. Mój problem został rozwiązany przy użyciu tych parametrów połączenia:
string sqlString = " Data Source = (LocalDB)\\MSSQLLocalDB;" + "AttachDbFilename = F:\\.........\\myDatabase.mdf; Integrated Security = True; Connect Timeout = 30";
W moim przypadku to inna sprawa. Baza danych przeszła w tryb pojedynczego użytkownika, a drugie połączenie z bazą danych pokazywało ten wyjątek. Aby rozwiązać ten problem, wykonaj poniższe czynności.
exec sp_who2i znajdź wszystkie połączenia z bazą danych „my_db”. Zabij wszystkie połączenia, robiąc, KILL { session id }gdzie identyfikator sesji to identyfikator SPID wymieniony przez sp_who2.USE MASTER;
EXEC sp_who2
USE MASTER;
ALTER DATABASE [my_db] SET MULTI_USER
GO
Nie widziałem tego wspomnianego w poprzednich numerach, więc pozwólcie, że wyrzucę inną możliwość. Może to być IFItestnieosiągalne lub po prostu nie istnieje. Na przykład, jeśli istnieje kilka konfiguracji, każda z własną bazą danych, może się zdarzyć, że nazwa bazy danych nie została zmieniona na poprawną dla bieżącej konfiguracji.
Uwaga: jeśli korzystasz z usługi Windows do hostowania usługi sieciowej.
Musisz upewnić się, że Twoja usługa sieciowa używa właściwego konta logowania do łączenia się z SQL Server.
Zainspirowany odpowiedzią cyptusa, którego użyłem
_dbContext.Database.CreateIfNotExists();
na EF6 przed pierwszym kontaktem z bazą danych (przed wypełnieniem bazy danych).
Jeśli nie utworzyłeś bazy danych na swoim serwerze, pojawi się ten sam błąd logowania. Upewnij się, że baza danych istnieje przed zalogowaniem.
Napotkałem ten problem podczas próby zapisu do domyślnej bazy danych podanej w szablonie mvc asp.net. Wynikało to z faktu, że baza danych nie została jeszcze utworzona.
Aby utworzyć bazę danych i upewnić się, że jest dostępna, wykonaj następujące kroki:
Spowoduje to utworzenie bazy danych i uruchomienie w niej wszystkich niezbędnych migracji.
Najlepszym rozwiązaniem byłoby użycie zintegrowanego uwierzytelniania systemu Windows, ponieważ jest ono bezpieczniejsze niż uwierzytelnianie sql. Utwórz nowego użytkownika systemu Windows na serwerze sql z niezbędnymi uprawnieniami i zmień użytkownika IIS w ustawieniach zabezpieczeń puli aplikacji.
Czasami ten problem może się pojawić, jeśli otworzysz tę bazę danych na innym serwerze sql (na przykład, uruchomisz sql managment studio (SMS) i dodasz tę bazę danych) i zapomnisz zatrzymać ten serwer. W rezultacie - próbujesz połączyć aplikację z użytkownikiem już połączonym w tej bazie danych na innym serwerze. Aby to naprawić, spróbuj zatrzymać ten serwer przez Config. Dispatcher SQL Server.
Przepraszam za zły angielski. Z poważaniem, Ignat.
W moim przypadku aplikacja asp.net zazwyczaj bez problemu łączy się z bazą danych. Zauważyłem taki komunikat w logach. I włączyć logi serwera SQL i dowiem się następujący komunikat:
2016-10-28 10:27:10.86 Logon Login failed for user '****'. Reason: Failed to open the explicitly specified database '****'. [CLIENT: <local machine>]
2016-10-28 10:27:13.22 Server SQL Server is terminating because of a system shutdown. This is an informational message only. No user action is required.
Wygląda więc na to, że serwer się restartował, a serwer SQL, który wyłączał się nieco wcześniej niż aplikacja ASP.NET i baza danych nie były dostępne przez kilka sekund przed restartem serwera.
Nawet jeśli ustawiłeś login jako właściciel bazy danych i ustawiłeś mapowanie użytkownika dla bazy danych, która będzie używać loginu, sprawdź, czy rzeczywisty użytkownik DB (nie tylko login) ma rolę „właściciela”.
W moim przypadku korzystałem z usługi Windows pod tożsamością „System”. Błąd:
System.Data.SqlClient.SqlException (0x80131904):
Cannot open database "MyDbName" requested by the login. The login failed.
Login failed for user 'MYDOMAINNAME\HOSTNAME$'.
Problem w tym, że błąd jest bardzo mylący. Nawet po dodaniu loginu `` MYDOMAINNAME \ HOSTNAME $ '' do bazy danych i przyznaniu tego logowania sysadminowi oraz dodaniu użytkownika dla tego loginu do mojej docelowej bazy danych i uczynieniu tego użytkownika dbowner, nadal otrzymywałem ten sam błąd. Najwyraźniej musiałem zrobić to samo dla logowania 'NT AUTHORITY \ SYSTEM'. Po wykonaniu tej czynności udało mi się zalogować bez problemu. Nie wiem, dlaczego komunikat o błędzie narzeka „NAZWA_MÓJDOMY \ NAZWA_HOSTA $”. Usunąłem ten login i odpowiadającego mu użytkownika i wszystko nadal działa.