Question

我尝试使用具有特定默认架构的应用程序角色，以便于在没有架构指定的情况下使用SQL命令，即不合格的名称。我需要创建和使用4 +套完整的表+视图+等。（每个50-100个对象）都应该只在自己的架构中工作。

为了测试它，我创建了一个具有合适默认架构的应用程序角色。然后我使用＆＃39; sp_setapprole＆＃39;附加此角色，并且＆＃39; sp_unsetapprole＆＃39;恢复我之前的角色。这似乎有效，因为SCHEMA_NAME（）会返回预期的架构名称（以及＆＃39; dbo＆＃39;之前＆＃39;设置＆＃39;以及＆＃39; unset＆＃39;）。

在我的批准中，我尝试删除并创建一个表，然后将记录插入到创建的表中。放置/创建工作正常，但插入失败，因为它尝试将记录插入到“dbo”中具有类似名称的表中。架构（它没有获得许可）。

为什么我的（有目的的）不合格的表格引用突然变回“dbo＆＃39;即使我的批准默认架构是另一个？

当我选择＆＃39;时，它也会失败，再次默认为＆＃39; dbo＆＃39;。

我已授予我对指定架构的所有可能权限，并且只允许SELECT到dbo。

感谢任何帮助。

干杯

拉斯

Answer 1

这很棘手，因为对象解析基于解析批处理时的默认架构。所以像这样的批次：

DECLARE @cookie varbinary(8000);
exec sp_setapprole a_role,'P@ssword',  @fCreateCookie = true, @cookie = @cookie output 
--go
select * from t

即使a_role具有不同的默认架构，也会引用dbo.t.如果你把它分成两批，那么t将解析为a.t。

或者你在存储过程中使用静态SQL，它是相对于过程的模式解析的，而不是任何用户的default_schema。

除此之外，我不认为应用程序角色是正确的方法。您可以通过使用模拟而不是使用应用程序角色来更简单地完成此操作。 EG授予应用程序用户模仿仅在特定模式中具有权限的用户的权利。类似的东西：

    create role app_users
    create user a_user without login with default_schema=a
    grant select, insert, update, delete, execute on schema::a to a_user
    grant impersonate on user::a_user to app_users

    go

    execute as user='a_user'
      select * from t  --resolves to a.t
      select * from dbo.t --fails
    revert

使用应用程序角色设置默认架构 - 命令意外地使用dbo

1 个答案: