关于在SQL-SERVER里调用COM组件

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数据库，那么关于此类数据的操作，似乎用这样的方法就是最好的补救。

个人觉得有点剑走偏锋的感觉，虽然很锋利，但是难免伤到自己