在SQL Server MS 2012中,服务器主体不能访问当前安全上下文中的数据库

我试图访问我的托pipe服务器的数据库通过SQL Serverpipe理工作室,一切,直到login罚款,但是当我使用命令use myDatabase它给了我这个错误:

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

我search了,主机服务提供商已列出此问题的修复程序。

但是,这不适合我,可能是因为它是用于SQL Server Management Studio 2008,但是我正在使用SQL Server Management Studio 2012。

这可能是一个问题吗? 如果是的话,谁能告诉我在SSMS 2012的替代scheme?

检查您的用户是否映射到您尝试login的数据库。

我们在PROD环境中向SSRS部署报告时发生同样的错误。 发现问题甚至可以通过“使用”声明进行复制。 解决scheme是将用户的GUID帐户引用与所讨论的数据库重新同步(即像恢复数据库之后使用“sp_change_users_login”一样)。 附有股票(光标驱动)脚本以重新同步所有帐户:

 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 

在我的情况下,这个消息是由一个同义词造成的,这个同义词在数据库名称中无意中包含了“对象名称”。 当我用新名称恢复数据库时,同义词仍指向旧的数据库名称。 由于用户在旧数据库中没有权限,因此出现了该消息。 为了解决这个问题,我删除并重新创build了同义词,而不用数据库名称限定对象名称:

  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 

我在vb.net中使用服务器pipe理对象(SMO)时遇到了同样的错误(我相信它在C#中是一样的)

技术人员乔对最初的post的评论是一个有用的警告,在共同主持,许多额外的事情正在进行。 花了一点时间才弄明白,但是下面的代码显示了如何在访问SQL数据库的方式上非常具体。 只要SMO调用在共享主机环境中不是特定的,就会显示“服务器主体.​​..”错误。

代码的第一部分是针对本地的SQL Express服务器,并依赖于简单的Windows身份validation。 这些示例中使用的所有代码均基于Robert Kanasz在本代码项目网站文章中的SMO教程:

  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 

上面的代码find了本地SQLEXPRESS服务器上每个数据库的.mdf文件,因为身份validation是由Windows处理的,并且在所有数据库中都是广泛的。

在下面的代码中有两个部分迭代.mdf文件。 在这种情况下,只有寻找文件组的第一个迭代起作用,并且它只能find一个文件,因为连接只是在共享主机环境中的一个数据库。

第二个迭代是以上工作的迭代的副本,因为它被写入的方式试图访问共享环境中的第一个数据库,而不是用户ID /密码适用的方式,所以立即窒息。 SQL服务器以“服务器主体.​​..”错误的forms返回授权错误。

 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 

在第二个迭代循环中,代码编译得很好,但是由于SMO没有设置为使用精确的语法精确地访问正确的数据库,所以这种尝试失败了。

正如我刚刚学习SMO,我认为其他新手可能会欣赏,知道这个错误也有一个更简单的解释 – 我们只是编写错误。