我有以下设置:
有一个SQL Server数据库,其中有几个表设置了触发器(收集历史数据)。这些触发器是带有EXECUTE AS 'HistoryUser'
的CLR存储过程。 HistoryUser
用户是数据库中的简单用户,无需登录。它具有足够的权限来读取所有表并写入历史表。
当我备份数据库然后将其还原到另一台计算机(在这种情况下为虚拟机,但无关紧要)时,触发器不再起作用。事实上,不再模仿用户工作了。甚至是一个简单的陈述,比如这个
exec ('select 3') as user='HistoryUser'
产生错误:
无法作为数据库主体执行,因为主体“HistoryUser”不存在,此类主体不能被模拟,或者您没有权限。
我read in MSDN如果数据库所有者是域用户,则会发生这种情况,但事实并非如此。即使我将其改为其他任何东西(他们推荐的解决方案),这个问题仍然存在。
如果我在没有登录的情况下创建另一个用户,我可以使用它进行模拟。也就是说,这很好用:
create user TestUser without login
go
exec ('select 3') as user='TestUser'
我不想重新创建所有这些触发器,所以有什么方法可以使现有的HistoryUser
工作吗?
答案 0 :(得分:5)
检测孤立用户,然后通过链接登录来解决。
<强> DETECT:强>
USE&lt; database_name&gt ;;
走;
sp_change_users_login @Action =&#39;报告&#39 ;;
走;
<强> RESOLVE:强>
以下命令重新链接&lt; login_name&gt;指定的服务器登录帐户。与&lt; database_user&gt;指定的数据库用户:
USE&lt; database_name&gt ;;
GO
sp_change_users_login @Action =&#39; update_one&#39;,
@UserNamePattern =&#39;&lt; database_user&gt;&#39;,
@LoginName =&#39;&LT; LOGIN_NAME&GT;&#39 ;;
GO
答案 1 :(得分:4)
触发器执行的用户帐户是什么。
您需要为该用户帐户HistoryUser授予该用户IMPERSONATE特权。
GRANT IMPERSONATE ON USER:: YourUser TO HistoryUser
此处有更多详情
答案 2 :(得分:4)
将数据库从一台机器移动到另一台机器后出现的这类问题通常涉及不匹配的SID,尽管我不确定它是否或如何适用于您的案例。尝试删除并重新创建数据库用户,确保恢复其对这些表的权限。
答案 3 :(得分:2)
这是一个“孤儿用户”。它不会工作。文件说明了这一点。 :-( 修复“孤立用户”状态,它将再次起作用