我遇到了授予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