sql server 2005 以上
begin   try
begin   tran
--sql语句
commit  tran
end   try
begin catch 
rollback
end catch

解决方案 »

  1.   

    USE AdventureWorks;
    GOBEGIN TRY
        -- Generate a divide-by-zero error.
        SELECT 1/0;
    END TRY
    BEGIN CATCH
        SELECT ERROR_LINE() AS ErrorLine;
    END CATCH;
    GO
      

  2.   

    同志们,我就是因为try/catch无效才来这边提问的...这个系统有一个非常强劲的地方,就是SQL语句中的try/catch是无效的,具体原因我也没搞明白...发贴之前我做了个实验 BEGIN TRY
    INSERT INTO TestTable VALUES (@path + '\' + @name)
    END TRY
    BEGIN CATCH
    INSERT INTO TestTable VALUES ('err')
    END CATCH然后TestTable里面的那个字段长度只有5,所以应该是能插入一个err的,但结果还是挂掉了。所以我想问问看有什么全局的设置可以做到?
      

  3.   

    挂掉了就是整个系统再也不响应了,猜测是死循环了,因为在挂掉期间,只需要把表的字段调成2000,系统居然就能恢复。
    当然如果不理他,那挂掉5分钟之后系统会重新开始响应,只是之前的那个任务就消失了...
    问题是,这个是一个Web系统,5分钟不响应就意味着整个Web上所以的人都得等,当然其他页面还是继续工作的,就是这个Insert任务5分钟内无效...所以,继续求助...有啥全局设置能让.net收不到Exception
      

  4.   

    如果实在没办法,那看来我得去试试service boker了,在另一个线程里面做,挂掉了应该也不会影响系统吧...
      

  5.   

    我听说过用service boker能做异步的触发,请问有谁了解这方面的资料么?
      

  6.   

    感觉楼主的思路有些问题:不要考虑SQL中有什么办法可以屏蔽掉错误,而是想办法让你触发器的代码如何不出错,这才是解决问题的真正方法。
      

  7.   

    楼上的说法很有道理,不过问题在于诸如网络连接超时之类的错误是我好像无法控制的...
    而这个触发器中有一个任务就是要读取远程的文件,上次的爆发就是因为读取超时造成的。不过晚上花了点时间用sql profile做了个trace之后发现,之前我的有一个猜测错了...他程序里面没有什么死循环,但我用脚本查了一下之后发现存在一个挂起操作。我印象中单表死锁是由于一个写操作锁掉的列在索引中被读操作引用造成的,不过我一直认为只有UPDATE才有可能造成这个问题,他的逻辑是INSERT FROM SELECT之后SELECT这张表,难道这个也可能会造成死锁?而且按照之前的情况描述,比较古怪的就是只有触发器出错的时候才会挂起,AFTER触发器中出错,对于插入操作本身难道有什么影响么?