sql-server - microsoft - sql server management studio 2017

El servidor principal no puede acceder a la base de datos bajo el contexto de seguridad actual en SQL Server MS 2012

Question

Estoy intentando acceder a la base de datos de mi servidor de alojamiento a través de SQL Server Management Studio, todo hasta que el inicio de sesión sea use myDatabase , pero cuando uso el comando use myDatabase me da este error:

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

He buscado y los proveedores de servicios de alojamiento han enumerado this solución para el problema.

Pero esto no funciona para mí, probablemente porque es para SQL Server Management Studio 2008, sin embargo, estoy usando SQL Server Management Studio 2012.

Puede ser esto un problema? Y si es así, ¿alguien me puede decir cuál es su alternativa en SSMS 2012?

Answer 1

Compruebe si su usuario está asignado a la base de datos que está intentando iniciar sesión.

Answer 2

En mi caso, el mensaje fue causado por un sinónimo que inadvertidamente incluyó el nombre de la base de datos en el "nombre del objeto". Cuando restauré la base de datos con un nuevo nombre, el sinónimo aún apuntaba al nombre anterior de la base de datos. Como el usuario no tenía permisos en la base de datos anterior, apareció el mensaje. Para solucionarlo, descarté y recreé el sinónimo sin calificar el nombre del objeto con el nombre de la base de datos:

    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

Answer 3

Encontré el mismo error al usar Server Management Objects (SMO) en vb.net (estoy seguro de que es lo mismo en C #)

El comentario de Techie Joe sobre la publicación inicial fue una advertencia útil de que en el alojamiento compartido están sucediendo muchas cosas más. Tomó un poco de tiempo para averiguarlo, pero el siguiente código muestra cómo uno tiene que ser muy específico en la forma en que accede a las bases de datos SQL. El error de "servidor principal ..." parecía aparecer cada vez que las llamadas SMO no eran precisamente específicas en el entorno de alojamiento compartido.

Esta primera sección del código estaba en contra de un servidor SQL Express local y dependía de la autenticación simple de Windows. Todo el código utilizado en estas muestras se basa en el tutorial SMO de Robert Kanasz en este artículo del sitio web de Code Project :

  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

El código anterior encuentra los archivos .mdf para cada base de datos en el servidor local SQLEXPRESS muy bien porque la autenticación es manejada por Windows y es amplia en todas las bases de datos.

En el siguiente código hay 2 secciones iterando para los archivos .mdf. En este caso, solo funciona la primera iteración que busca un grupo de archivos, y solo encuentra un solo archivo porque la conexión es solo a una única base de datos en el entorno de alojamiento compartido.

La segunda iteración, que es una copia de la iteración que trabajó anteriormente, se ahoga de manera inmediata porque, en la forma en que está escrita, intenta acceder a la primera base de datos en el entorno compartido, que no es a la que se aplica la ID / contraseña de usuario, por lo el servidor SQL devuelve un error de autorización en forma de error ''servidor 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

En ese segundo bucle de iteración, el código compila bien, pero debido a que SMO no se configuró para acceder con precisión a la base de datos correcta con la sintaxis precisa, ese intento falla.

Como estoy aprendiendo SMO, pensé que a otros novatos les gustaría saber que también hay una explicación más simple para este error: simplemente lo codificamos mal.

Answer 4

Pasé bastante tiempo luchando con este problema y luego me di cuenta de que estaba cometiendo un simple error en el hecho de que había olvidado a qué base de datos en particular me dirigía mi conexión. Estaba usando la ventana de conexión estándar de SQL Server para ingresar las credenciales:

Tuve que verificar la pestaña Propiedades de la conexión para verificar que estaba eligiendo la base de datos correcta para conectarme. Había dejado accidentalmente la opción Conectar a la base de datos aquí configurada como una selección de una sesión anterior. Es por eso que no pude conectarme a la base de datos con la que creía estar intentando conectarme.

Tenga en cuenta que debe hacer clic en el botón Options >> para que aparezcan las Propiedades de conexión y otras pestañas.

Answer 5

Tuvimos el mismo error a pesar de que el usuario estaba correctamente asignado al inicio de sesión.

Después de intentar eliminar al usuario, se descubrió que algunos SP contenían "con ejecutar como" ese usuario.

El problema se resolvió descartando esos SP, eliminando al usuario, recreando al usuario vinculado al inicio de sesión y recreando los SP.

Posiblemente llegó en este estado desde la restauración desde la copia de seguridad (durante un momento en que el inicio de sesión relacionado no existía) o la sincronización de esquema masivo (si es posible crear un SP con execute como aunque el usuario no exista). También podría tener relacionado con esta respuesta

Answer 6

Tuvimos el mismo error al implementar un informe en SSRS en nuestro entorno de PROD. Se encontró que el problema podría incluso reproducirse con una declaración de "uso". La solución fue volver a sincronizar la referencia de la cuenta GUID del usuario con la base de datos en cuestión (es decir, usar "sp_change_users_login" como lo haría después de restaurar un db). Se adjunta una secuencia de comandos stock (cursor driven) para volver a sincronizar todas las cuentas:

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