Sql-server里可以調用基于IDispatch的COM組件
有興趣的可以自己去查SQL幫助里的sp_OACreate、sp_OAMethod、sp_OADestroy等存儲過程的用法。
下面是我在一個短信報警的小項目里的一些sql代碼,報警信息通過各類軟件插入到sql-server里,然后通過觸發器調用組件,并發送短信到指定手機上去,實現自動報警功能。
//測試數據庫的觸發器
ALTER TRIGGER message_Trigger1
ON dbo.message
FOR INSERT /*, UPDATE, DELETE */
AS
/* IF UPDATE (column_name) ...*/
begin
declare @PhoneNum nvarchar(50)
declare @Content nvarchar(140)
declare @MessageId nvarchar(70)
declare @index int
declare @hr int
declare @object int
select @PhoneNum = phone_num, @Content = Content, @MessageId = message_id from inserted
select @index = 1
/*調用COM發送短信*/
begin
EXEC @hr = sp_OACreate '{26850DDA-862C-44FF-9232-282937F2CA4B}',@object OUT
if @hr = 0
begin
exec @hr=sp_OAMethod @object,'SendMsg',NULL,@Content,@PhoneNum,@index,@MessageId
exec sp_OADestroy @object
end
end
end
這里的代碼可以說是沒有問題,但是也可以說是有很大的問題。
關鍵就在于組件的SendMsg方法,為什么呢?我可以舉出幾個我實際碰到的問題來做具體說明。
最主要有2點
第1:此COM組件是否為進程內組件,組件內部代碼是否足夠強壯
第2:創建組件和銷毀組件及組件方法要盡最大可能的快速
我對上述兩點做一個說明
如果COM組件為進程內組件的話,意味著此組件被sql-server加載,如果此代碼不夠健壯,那么,由于組件本身導致的掛起,崩潰,會直接影響到整個sql-server,那么情況是非常嚴重的,這種錯誤,發生一次就足以要了你的小命,如果恰好在客戶的臉上爆炸的話……
解決的方法只有這樣:首先保證你的組件代碼足夠強壯,強壯到不能再強壯為止。還有就是盡量讓組件不要是進程內的,如果已經是DLL了,那么就交給COM Catalog來管理。這樣就解決了因為組件崩潰掛起導致sql-server產生問題。
其次,要讓你的組件的創建、方法調用、銷毀都快到不能再快,要快到幾乎瞬間就完成。否則如果突然有海量數據進來,你的觸發器來不及反映,那你的數據就可能被回滾掉,而且這些數據很重要,那你就等著被Fire吧 L 5555~~~~~
如果非要用這種方法的話,那么就要完成我上面提到的2點,并且最好啟用COM 對象池。如果方法需要很長時間才能返回,并且無法優化了,那么就把這些方法移出去,把這些動作在另外的程序里做,讓COM方法立刻返回。
總而言之,言而總之,在系統集成的時候如果幾個開發廠商沒有商量好接口,并且都采用SQL-SERVER數據庫,那么關于此類數據的操作,似乎用這樣的方法就是最好的補救。
個人覺得有點劍走偏鋒的感覺,雖然很鋒利,但是難免傷到自己
溫柔的毒藥 2005-12-30
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com