DBCC CHECKIDENT在臨時表上拋出權限錯誤，導致用戶錯誤

我作爲非SA用戶'bhk'登錄到SQL Server 2005數據庫，該用戶只是「公共」服務器角色的成員。以下代碼嘗試在由用戶'bhk'調用的存儲過程中執行。這行代碼...DBCC CHECKIDENT在臨時表上拋出權限錯誤，導致用戶錯誤

TRUNCATE TABLE #Table1 
DBCC CHECKIDENT('#Table1', RESEED, @SequenceNumber) WITH NO_INFOMSGS

原因這個錯誤...

用戶 '客戶' 沒有權限運行DBCC CHECKIDENT爲對象
'＃Table1__00000000007F'。

我知道運行DBCC CHECKIDENT所需的權限...
來電必須擁有該表，或者是sysadmin固定服務器角色的成員，db_owner固定數據庫角色，或者db_ddladmin固定的數據庫角色。

所以我有兩個問題：

由於「BHK」被調用存儲過程，創建一個臨時表，不應該「BHK」是所有者和被允許運行DBCC CHECKIDENT？
爲什麼錯誤消息返回該用戶'guest' 沒有權限？據我所知，我不是作爲'客人'登錄。

任何幫助將不勝感激。

來源

2008-10-09 Brad Knowles

這裏是一個替代的解決方案，如果你需要重新播種逾1

TRUNCATE #Table1 

SET IDENTITY_INSERT #Table1 ON 

INSERT INTO #Table1 (TableID) -- This is your primary key field 
VALUES (@SequenceNumber - 1) 

SET IDENTITY_INSERT #Table1 OFF 

DELETE FROM #Table1

這是什麼做的是將IDENTITY上臨時表中的序列號，可能工作，允許您添加一個帶有顯式ID的行。然後你可以刪除這一行，但是進一步的插入應該從最後一個序列號開始。

來源

2008-10-13 15:39:05

您寫道：

「主叫方必須擁有該表，或者是sysadmin固定服務器角色固定的db_owner的成員。」

所以（如果不是bug），根據Lieutenant Columbo's無可挑剔的邏輯，每個前提必須是假的。這意味着，即使他創建了它，調用者也不擁有該表，即，。

實際上，默認情況下，似乎在tempd 中創建的所有對象都由dbo所有。你可以檢查它，如果你不按照查詢分析器：使用低權限用戶

連接到數據庫。
執行：CREATE TABLE #NotMyTable (TestID int identity)
連接到相同的SQL Server 的tempdb中作爲DBO
執行：SELECT user_name(uid) FROM sysobjects WHERE name LIKE '#NotMyTable%'

你會看到，DBO是臨時表的所有者。

那麼，有什麼可以解決的？

（前言：我不喜歡那種操控的，但智力刺激是推動我... ;-)）

所以，你可以另寫存儲過程，而更新的UID在tempdb的sysobjects中添加到您的用戶的值（shiver！）。我只在查詢分析器中測試過它。更新後，我可以執行您的DBCC CHECKIDENT命令。

來源

2008-10-11 15:16:26 splattne

雖然這可能會起作用，但我同意不喜歡那種操縱。 – 2008-10-22 16:17:12

執行TRUNCATE和CHECKIDENT命令的備用解決方案是簡單地刪除並重新創建臨時表。例如。

DROP TABLE #Table1 

CREATE TABLE #Table1 
(
    .... 
)

雖然這可能不是最有效的解決方案。

來源

2008-10-13 09:07:27

你是對的。但是，在我的情況下，目標是將標識列重置爲除1之外的其他值。Drop/Create僅將列重置爲1，並且似乎不允許變量作爲IDENTITY SEED參數的值。 – 2008-10-13 15:01:03

您可以通過完全限定tempdb表來完成此操作。

DBCC CHECKIDENT([tempdb..#Table1], RESEED, @SequenceNumber) WITH NO_INFOMSGS

來源

2011-02-08 17:00:03 Bob

我剛碰到這個。我得到的答案是爲tempdb數據庫中的相關帳戶提供權限，在這些數據庫中創建這些表。

來源

2012-04-30 15:23:47

我通過以sa身份登錄並檢查我正在使用的登錄名來解決此問題，以確保它具有映射到具有ddladmin成員身份的tempdb中的用戶 – jocassid 2016-09-01 20:37:00

DBCC CHECKIDENT在臨時表上拋出權限錯誤，導致用戶錯誤

回答

相關問題