2013-09-25 8 views
59

Próbuję uzyskać dostęp do bazy danych mojego serwera hostingowego za pomocą SQL Server Management Studio, wszystko do momentu zalogowania się jest w porządku, ale kiedy używam polecenia use myDatabase to daje mi ten błąd:Główny administrator serwera nie może uzyskać dostępu do bazy danych w bieżącym kontekście zabezpieczeń w SQL Server MS 2012

The server principal "****" is not able to access the database "****" under the current security context. 

i przeszukiwane przez i hosting usługodawcy wymienia this poprawkę dla tego problemu.

Ale to nie działa dla mnie prawdopodobnie dlatego, że jest dla SQL Server Management Studio 2008 jednak używam SQL Server Management Studio 2012.

To może być problem? A jeśli tak, to czy ktoś może powiedzieć mi o swojej alternatywie w SSMS 2012?

+2

"Hosting usługodawców"? Czy mówimy dedykowane czy udostępniane? Jeśli jest to dzielony serwer hostingowy, zdecydowanie zalecamy skontaktowanie się z dostawcą usług hostingowych w celu uzyskania pomocy. SQL w środowisku hostingu dzielonego jest notorycznie kłopotliwy i problematyczny. Nie ma to nic wspólnego z produktem, ale z zasadami, które dostawcy usług hostingowych stosują do serwera (ów). Każda firma hostingowa ma swój własny sposób na wykorzystanie SQL lub tak się wydaje. –

Odpowiedz

52

Sprawdź, czy twój użytkownik jest zmapowany do DB, do którego próbujesz się zalogować.

+27

jak to robisz? – Graham

+2

@Graham Użyj programu SQL Server Management Studio, aby sprawdzić użytkownika lub zobacz tę odpowiedź: http://stackoverflow.com/a/9356725/804773 – Grambot

+3

Proponuję szukać wyzwalaczy, dlatego właśnie otrzymałem tę wiadomość. był wyzwalaczem wykonującym pewne czynności w innej bazie danych, w której mój użytkownik nie był autoryzowany. – DanielV

12

Wystąpił ten sam błąd podczas wdrażania raportu do SSRS w naszym środowisku PROD. Stwierdzono, że problem można nawet odtworzyć za pomocą instrukcji "użytkowania". Rozwiązaniem było ponowne zsynchronizowanie referencji konta GUID użytkownika z daną bazą danych (tj. Użycie "sp_change_users_login", tak jak po przywróceniu bazy danych). Zasobu (kursor napędzany) skrypt ponownie synchronizację wszystkich kont dołączony jest:

USE <your database> 
GO 

-------- Reset SQL user account guids --------------------- 
DECLARE @UserName nvarchar(255) 
DECLARE orphanuser_cur cursor for 
     SELECT UserName = su.name 
     FROM sysusers su 
     JOIN sys.server_principals sp ON sp.name = su.name 
     WHERE issqluser = 1 AND 
      (su.sid IS NOT NULL AND su.sid <> 0x0) AND 
      suser_sname(su.sid) is null 
     ORDER BY su.name 

OPEN orphanuser_cur 
FETCH NEXT FROM orphanuser_cur INTO @UserName 

WHILE (@@fetch_status = 0) 
BEGIN 
--PRINT @UserName + ' user name being resynced' 
exec sp_change_users_login 'Update_one', @UserName, @UserName 
FETCH NEXT FROM orphanuser_cur INTO @UserName 
END 

CLOSE orphanuser_cur 
DEALLOCATE orphanuser_cur 
+1

Pracowałem dla mnie Dziękuję. Skopiowałem bazę danych z uwierzytelnianiem serwera SQL do mojego serwera testowego i było niedostępne. Teraz jest to – MikeH

+0

Jeśli Użytkownik istnieje w bazie danych, ale nie utrwala mapowania do Logowania, usuwając tego Użytkownika za pomocą Eksploratora Obiektów SSMS, to ponowne mapowanie Loginu działa dla mnie. W przeciwnym razie podejrzewam, że rozwiązanie zaproponowane powyżej wymagałoby podjęcia. – jjt

3

W moim przypadku, wiadomość została spowodowana przez synonim który przypadkowo włączone nazwę bazy danych w polu „Nazwa obiektu”. Kiedy przywróciłem bazę danych pod nową nazwą, synonim nadal wskazywał na starą nazwę bazy danych. Ponieważ użytkownik nie miał uprawnień w starym DB, pojawił się komunikat. Aby ustalić, rzuciłem i odtworzył synonim bez kwalifikacyjna nazwę obiektu z nazwą bazy danych:

USE [new_db] 
GO 

/****** Object: Synonym [dbo].[synTable] Script Date: 10/15/2015 9:45:01 AM ******/ 
DROP SYNONYM [dbo].[synTable] 
GO 

/****** Object: Synonym [dbo].[synTable] Script Date: 10/15/2015 9:45:01 AM ******/ 
CREATE SYNONYM [dbo].[synTable] FOR [dbo].[tTheRealTable] 
GO 
0

natknąłem się ten sam błąd podczas korzystania z obiektów Management Server (SMO) w VB.NET (jestem pewien, że to to samo w języku C#)

Komentarz Techie Joe na temat pierwszego wpisu był przydatnym ostrzeżeniem, że we wspólnym hostingu dzieje się wiele dodatkowych rzeczy. Potrzeba było trochę czasu, aby dowiedzieć się, ale poniższy kod pokazuje, jak trzeba być bardzo specyficznym w sposobie dostępu do baz danych SQL. Błąd "server principal ..." wydawał się pojawiać, gdy wywołania SMO nie były dokładnie określone we wspólnym środowisku hostingowym.

Pierwsza sekcja kodu była skierowana przeciwko lokalnemu serwerowi SQL Express i polegała na prostym uwierzytelnianiu systemu Windows. Cały kod stosowany w tych próbkach są oparte na kursie SMO Roberta Kanasz w tym Code Project website article:

Dim conn2 = New ServerConnection() 
    conn2.ServerInstance = "<local pc name>\SQLEXPRESS" 
    Try 
    Dim testConnection As New Server(conn2) 
    Debug.WriteLine("Server: " + testConnection.Name) 
    Debug.WriteLine("Edition: " + testConnection.Information.Edition) 
    Debug.WriteLine(" ") 

    For Each db2 As Database In testConnection.Databases 
     Debug.Write(db2.Name & " - ") 
     For Each fg As FileGroup In db2.FileGroups 
     Debug.Write(fg.Name & " - ") 
     For Each df As DataFile In fg.Files 
      Debug.WriteLine(df.Name + " - " + df.FileName) 
     Next 
     Next 
    Next 
    conn2.Disconnect() 

    Catch err As Exception 
    Debug.WriteLine(err.Message) 
    End Try 

Powyższy kod wyszukuje pliki .mdf dla każdej bazy danych na lokalnym serwerze SQLEXPRESS dobrze ponieważ uwierzytelnianie jest obsługiwane przez Windows i jest szeroki we wszystkich bazach danych.

W poniższym kodzie znajdują się 2 sekcje iterujące dla plików .mdf. W tym przypadku działa tylko pierwsza iteracja szukająca grupy plików i znajduje tylko jeden plik, ponieważ połączenie ma tylko jedna baza danych w udostępnianym środowisku hostingu.

Druga iteracja, która jest kopią iteracji, która działała powyżej, dławi się natychmiast, ponieważ sposób, w jaki jest zapisana, próbuje uzyskać dostęp do pierwszej bazy danych w środowisku współużytkowanym, która nie jest tą, do której identyfikator użytkownika/Hasło jest stosowane, więc serwer SQL zwraca błąd autoryzacji w postaci błędu "serwer główny ...".

Dim sqlConnection1 As New System.Data.SqlClient.SqlConnection 
sqlConnection1.ConnectionString = "connection string with User ID/Password to a specific database in a shared hosting system. This string will likely also include the Data Source and Initial Catalog parameters" 
Dim conn1 As New ServerConnection(sqlConnection1) 
Try 
    Dim testConnection As New Server(conn1) 
    Debug.WriteLine("Server: " + testConnection.Name) 
    Debug.WriteLine("Edition: " + testConnection.Information.Edition) 
    Debug.WriteLine(" ") 

    Dim db2 = testConnection.Databases("the name of the database to which the User ID/Password in the connection string applies") 
    For Each fg As FileGroup In db2.FileGroups 
    Debug.Write(fg.Name & " - ") 
    For Each df As DataFile In fg.Files 
     Debug.WriteLine(df.Name + " - " + df.FileName) 
    Next 
    Next 

    For Each db3 As Database In testConnection.Databases 
    Debug.Write(db3.Name & " - ") 
    For Each fg As FileGroup In db3.FileGroups 
     Debug.Write(fg.Name & " - ") 
     For Each df As DataFile In fg.Files 
     Debug.WriteLine(df.Name + " - " + df.FileName) 
     Next 
    Next 
    Next 

    conn1.Disconnect() 

Catch err As Exception 
    Debug.WriteLine(err.Message) 
End Try 

W tej drugiej iteracji pętli, kod kompiluje grzywny, ale ponieważ nie był ustawiony SMO właśnie dostęp do bazy danych z poprawną dokładnej składni, że próba nie powiedzie się.

Po prostu uczę się SMO Myślałem, że inni nowicjusze mogą docenić, wiedząc, że istnieje również prostsze wyjaśnienie tego błędu - po prostu zakodowaliśmy to źle.

Powiązane problemy