我遇到了授予SQL Server 2005中特定存储过程的EXECUTE权限不起作用的问题。一些测试人员与权限混淆 - 并发现如果他们也授予了对存储过程的CONTROL权限 - 那么它运行良好。他们现在确信，授予CONTROL权限是一种方式。应该在SQL Server 2005中的存储过程上给予CONTROL权限吗？
我知道这不可能是真的 - 事实上我认为真正的问题是用户没有选择/插入/更新/删除存储过程运行的表的权限。问题是，我似乎无法在网上找到证明它的任何东西。
我正确吗？有没有人知道有关这方面的任何文件？
在此先感谢。
更多信息在回应意见： 存储过程正在做多个删除。它首先删除将被删除的“主”记录孤立的所有记录，然后删除父记录。
另外，我们看到的错误表明用户没有足够的权限 - 或者存储过程不存在。我们已经确认我们使用的是正确的用户，并且已向该用户授予EXECUTE权限。
如果存储过程是使用EXECUTE AS CALLER（我相信是默认值）创建的，那么调用者必须具有执行存储过程所需的所有权限，而不必执行该过程的EXECUTE。
从SQL Server文档EXECUTE AS：
来电指定内部 模块中的语句，模块的调用方的上下文 被执行。执行模块的用户 必须不仅在 模块本身上，而且还在由模块引用 的任何 数据库对象上都具有适当的权限 。
需要注意的是，因为使用所有权链的方式SQL Server进程的权限检查，这并不总是严格真实的，我猜对过程控制授予（赋予权属状况给予专营）是导致这些权限检查被绕过。
如果您使用EXECUTE AS OWNER创建过程，那么您不应该在过程上授予任何超出EXECUTE的权限。
执行应该是所有需要的。
存储过程是否访问它所在数据库之外的表？
如果是这样，请尝试在存储过程在同一数据库之外使用的表上设置适当的用户权限。
如果你只需要能够执行存储过程，那么明显的CONTROL权限是而不是要走的路。是的，它的工作方式与在本地系统帐户下运行您的网站的方式一样。
如果EXECUTE权限的授予者也是受影响的表的所有者，那么执行sp应该没有问题。否则，您应该授予显式权限或考虑使用ALTER AUTHORIZATION语句来调整所有权。
对于奖金可管理性，创建数据库角色以应用显式权限，而不是直接将其分配给用户。
这可能已经解决了，但在我的情况下，我需要授予控制权限（在测试服务器上，而不是活的）的原因是因为存储过程的原始开发人员在设计时错过了GO语句因此GRANT EXECUTE行在存储过程中。我们在现场修复了这个问题，但看起来修复程序从未在测试中实现过。
如果您给存储过程执行权限，它可以执行所有插入，更新和删除操作。你需要告诉我们该做什么。 – 2009-01-09 18:00:25