2013-09-25 9 views
59

Sto tentando di accedere al database del server di hosting tramite SQL Server Management Studio, tutto finché l'accesso non è corretto ma quando utilizzo il comando use myDatabase mi dà questo errore:L'identità del server non è in grado di accedere al database nel contesto di sicurezza corrente in SQL Server MS 2012

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

ho cercato più e fornitori di servizi di hosting ha elencato this correzione per il problema.

Ma questo non funziona per me probabilmente perché è per SQL Server Management Studio 2008 però sto utilizzando SQL Server Management Studio 2012.

Questo può essere un problema? E se sì di quanto possa qualcuno dirmi la sua alternativa in SSMS 2012?

+2

"Provider di servizi di hosting"? Stiamo parlando dedicato o condiviso? Se si tratta di un server di hosting condiviso, ti consiglio vivamente di contattare il tuo provider di hosting per assistenza. SQL in un ambiente di hosting condiviso è notoriamente bacato e problematico. Non ha nulla a che fare con il prodotto, ma le politiche che i provider di hosting applicano ai server. Ogni società di hosting ha il proprio modo di sfruttare SQL o così sembra. –

risposta

52

Verificare se l'utente è mappato al DB in cui si sta tentando di accedere.

+27

come si fa? – Graham

+2

@Graham Utilizzare SQL Server Management Studio per verificare l'utente o visualizzare questa risposta: http://stackoverflow.com/a/9356725/804773 – Grambot

+3

Suggerirei di cercare trigger, è stato questo il motivo per cui ho ricevuto questo messaggio, lì è stato un trigger che fa qualcosa in un altro database in cui il mio utente non era autorizzato. – DanielV

12

Abbiamo avuto lo stesso errore di distribuzione di un rapporto su SSRS nel nostro ambiente PROD. È stato trovato che il problema potrebbe anche essere riprodotto con una dichiarazione di "uso". La soluzione era risincronizzare il riferimento all'account GUID dell'utente con il database in questione (ad esempio, utilizzando "sp_change_users_login" come si farebbe dopo il ripristino di un db). Uno stock (guidato cursore) script per ri-sincronizzare tutti i conti è fissato:

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

Ha funzionato per me Grazie. Avevo copiato un database con un'autenticazione del server SQL sul mio server di test ed era inaccessibile. Ora è – MikeH

+0

Se l'Utente esiste nel database ma non riesce a mantenere una mappatura al Login, cancellando detto Utente tramite SSMS Object Explorer, quindi rimappando il Login ha funzionato per me. Altrimenti, sospetto che la soluzione sopra proposta debba essere presa. – jjt

3

Nel mio caso, il messaggio è stato causato da un sinonimo che includeva inavvertitamente il nome del database nel campo "Nome oggetto". Quando ho ripristinato il database con un nuovo nome, il sinonimo puntava ancora al vecchio nome del DB. Poiché l'utente non disponeva delle autorizzazioni nel vecchio DB, il messaggio è apparso. Per risolvere, ho lasciato cadere e ricreato il sinonimo senza qualificare il nome dell'oggetto con il nome del database:

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

ho incontrato lo stesso errore durante l'utilizzo di Server Management Objects (SMO) in vb.net (io sono sicuro che sia la lo stesso in C#)

Il commento di Joe sul post iniziale è stato un utile avvertimento che nell'hosting condiviso stanno accadendo molte cose aggiuntive. Ci è voluto un po 'di tempo per capire, ma il codice qui sotto mostra come si deve essere molto specifici nel modo in cui accedono ai database SQL. L'errore "server principal ..." sembrava apparire ogni volta che le chiamate SMO non erano precisamente specifiche nell'ambiente di hosting condiviso.

Questa prima sezione di codice era contro un server SQL Express locale e si basava su una semplice autenticazione di Windows. Tutto il codice utilizzato in questi campioni sono basati su tutorial SMO da Robert Kanasz in questo 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 

Il codice trova sopra i file con estensione mdf per ogni database sul server SQLEXPRESS locale proprio bene perché l'autenticazione viene gestita da Windows ed è ampio su tutti i database.

Nel seguente codice sono presenti 2 sezioni che iterano per i file .mdf. In questo caso, solo la prima iterazione alla ricerca di un filegroup funziona e trova solo un singolo file perché la connessione riguarda solo un singolo database nell'ambiente di hosting condiviso.

la seconda iterazione, che è una copia di iterazione che ha lavorato sopra, soffoca immediatamente perché il modo in cui è scritto che tenta di accedere al primo database nell'ambiente condiviso, che non è quello a cui l'ID utente/Applica la password, quindi il server SQL restituisce un errore di autorizzazione sotto forma di errore "server principal ...".

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 

In questa seconda iterazione del ciclo, il codice compila bene, ma perché SMO non era impostata per accedere proprio database corretto con la sintassi preciso, questo tentativo fallisce.

Mentre sto imparando SMO ho pensato che altri neofiti potrebbero apprezzare sapere che c'è anche una spiegazione più semplice di questo errore - abbiamo semplicemente sbagliato.

Problemi correlati