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