Le serveur principal n'est pas en mesure d'accéder à la base de données dans le contexte de sécurité actuel dans SQL Server MS 2012

Nous avons eu la même erreur déploiement d'un rapport de SSRS dans notre environnement de PROD. Il a été constaté que le problème pourrait même être reproduites avec une instruction “use”. La solution a été de re-synchronisation de l'utilisateur GUID compte de référence avec la base de données en question (c'est à dire, à l'aide de "sp_change_users_login" comme vous le feriez après la restauration de la base de données). Un stock (curseur driven) script pour re-synchroniser tous les comptes est joint:

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

Dans mon cas, le message a été causé par un synonyme qui inclus par inadvertance le nom de base de données dans le "nom d'objet". Quand j'ai restauré la base de données sous un nouveau nom, le synonyme encore souligné l'ancien nom DB. Puisque l'utilisateur n'a pas les autorisations dans le vieux DB, le message est apparu. Pour corriger, j'ai supprimé et recréé le synonyme sans qualification le nom de l'objet avec le nom de la base:

    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

J'ai rencontré la même erreur lors de l'utilisation de Server Management Objects (SMO) dans vb.net (je suis sûr que c'est la même chose en C#)

Technophile Joe commentaire sur le post initial était un avertissement utile que dans d'hébergement partagé beaucoup de choses sont en cours. Il a fallu un peu de temps à comprendre, mais le code ci-dessous montre comment on a d'être très précis dans la manière dont ils accèdent à des bases de données SQL. Le " serveur principal...' erreur semblait montrer chaque fois que le SMO appels n'étaient pas précisément spécifiques dans l'environnement d'hébergement partagé.

Cette première section de code a été à l'encontre d'un local de SQL server Express et s'appuyait sur la simple Authentification Windows. Tous les codes utilisés dans ces exemples sont basés sur le SMO tutoriel par Robert Kanasz dans ce Projet de Code site internet de l'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

Le code ci-dessus trouve le .les fichiers mdf pour chaque base de données sur les locaux SQLEXPRESS serveur juste bien parce que l'authentification est gérée par Windows et il est large à travers toutes les bases de données.

Dans le code suivant, il y a 2 sections de l'itération pour la .les fichiers mdf. Dans ce cas, seule la première itération la recherche d'un groupe de fichiers, et il ne trouve un seul fichier car la connexion est d'une seule base de données dans l'environnement d'hébergement partagé.

La deuxième itération, qui est une copie de l'itération qui a travaillé dessus, étouffe immédiatement parce que la façon dont il est écrit, il tente d'accéder à la 1ère base de données dans l'environnement partagé, ce qui n'est pas celle à laquelle l'ID Utilisateur/Mot de passe s'appliquent, de sorte que le SQL server renvoie une autorisation d'erreur dans la forme d'un " serveur principal...' erreur.

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

Dans cette deuxième itération de la boucle, le code se compile bien, mais parce que SMO n'était pas configuré pour accéder précisément à la base de données correcte avec la syntaxe précise, que la tentative échoue.

Que je suis en train d'apprendre SMO j'ai pensé à d'autres débutants pourraient apprécier de savoir il y a aussi une explication plus simple pour cette erreur - nous juste codé mal.

SQL Connexions sont définis au niveau du serveur, et doit être mappé à Utilisateurs dans des bases de données spécifiques.

Dans SSMS de l'explorateur d'objets, sous le serveur que vous voulez modifier, élargir de Sécurité > Connexions, puis double-cliquez sur l'utilisateur approprié qui permettra d'apporter de la "Connexion" Propriétés de la boîte de dialogue.

Sélectionnez Mappage de l'Utilisateur, qui vous fera découvrir toutes les bases de données sur le serveur, avec ceux ayant un mappage existant sélectionné. De là, vous pouvez sélectionner d'autres bases de données (et assurez-vous de sélectionner les rôles dans chaque base de données que l'utilisateur doit appartenir), puis cliquez sur OK pour ajouter des mappages.

Ces mappages peuvent être déconnectés après une restauration ou opération similaire. Dans ce cas, l'utilisateur peut encore exister dans la base de données mais n'est pas en fait associé à une connexion. Si cela se produit, vous pouvez exécuter les opérations suivantes pour restaurer la connexion:

USE {database};
ALTER USER {user} WITH login = {login}

Vous pouvez également supprimer le DB utilisateur et de le recréer à partir de la boîte de dialogue Propriétés de la Connexion, mais un rôle d'adhésions ou d'autres paramètres devront être recréés.