在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，我认为其他新手可能会欣赏，知道这个错误也有一个更简单的解释 – 我们只是编写错误。
