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數據庫，那么關于此類數據的操作，似乎用這樣的方法就是最好的補救。

個人覺得有點劍走偏鋒的感覺，雖然很鋒利，但是難免傷到自己