2011-07-28 41 views
0

我們在SQL Server 2000中有一些舊的存儲過程,它從一個用於用戶應用程序安全性的應用程序更新系統目錄,該用戶應用程序安全性綁定到SQL Server角色以利用SQL Server內置安全和NT登錄。SQL Server 2008 - 從存儲過程更新系統目錄

當我們遷移數據庫到SQL Server 2008,並嘗試運行這些存儲過程,我們得到SQL Server 2008中的錯誤

特設更新系統目錄是不允許的。

我四處搜索,發現從SQL Server 2005開始,MS不支持目錄更新(除非使用專用管理員連接(DAC))。

如果任何人都可以幫助我如何在新版本或任何其他選擇(如在Sql服務器運行的.Net代碼??),這將是偉大的。

下面

update sysusers 
set roles = convert(varbinary(2048), substring(convert(binary(2048), roles), 1, @ruidbyte-1) 
      + convert(binary(1), ([email protected]) & substring(convert(binary(2048), roles), @ruidbyte, 1)) 
      + substring(convert(binary(2048), roles), @ruidbyte+1, [email protected])), 
    updatedate = getdate() 
where uid = @memuid 

delete from syspermissions where grantee = @uid 

delete from sysusers where uid = @uid 

insert into sysusers 
values(@uid, 0, @rolename, NULL, 0x00, getdate(), getdate(), @owner, NULL) 
+3

基本上,那些系統目錄**視圖**(在SQL Server 2005/2008及更高版本中)就是這樣 - 只讀視圖導入系統表。這些系統表不能用普通代碼編輯 - 既不是T-SQL也不是SQL-CLR。您需要使用「官方」,已發佈的API(例如「CREATE USER」或「DROP USER」)來執行此類操作 - 當您這樣做時,系統目錄視圖將自動更新 –

+0

與@marc_s同意 - 請使用記錄和支持的方法安全。 –

回答

1

一些樣本查詢,沒有常規的理由來更新SQL Server系統表。永遠。

有一整套命令和系統存儲過程可以在所有版本的SQL Server中正確執行。

你不能無論如何,你注意的是:有沒有黑客或替代方法

+0

謝謝你的細節。什麼會出現一些equivalemnt系統存儲過程做從syspermissions以下刪除其中持證= #uid 從sysusers中刪除其中uid = #uid INSERT INTO的sysusers 值(#uid,0,#rolename,NULL,0×00, getdate(),getdate(),#owner,NULL) –

+0

DROP USER和CREATE USER(只是搜索)。刪除用戶刪除權限 – gbn

+0

不使用sp_addrolemember系統存儲過程的原因,允許非dbo_用戶安全地訪問和執行sp_addrolemember的修訂副本。這個限制在SQL 2008中是否仍然存在? –

0

更新系統表可以是危險的任務,因爲這可能會導致意想不到的結果。所以在你做之前,只要確保你對你正在做的事情非常有信心。建議您對原始數據庫的副本進行更改以防止數據庫中出現不需要的結果或崩潰。

可能的方式可以是:

  1. 使用DAC。您可以在Google上搜索後獲取該技術。這更多的是黑客的系統表。

  2. 使用下面的代碼:

的sp_configure '允許更新',1 去

//你的代碼

重新配置與重寫 去

重新配置將配置回你的數據庫。 設置'允許更新'爲'1'將允許您更新系統表。

但最好的辦法是找到你的任務的另一種選擇。

相關問題