SQL Server 2005でのTRY ... CATCHの成功戦略

Question

SQL Server 2005でTRY ... CATCHを利用するためにいくつかのコードを変更しています。

エラーの詳細を示し、開いているトランザクションをロールバックしてエラーを発生させるシステム関数を呼び出すストアドプロシージャを作成しようと考えています。より良い方法がありますか？

Answer 1

私はTRY ... CATCHを使用していますが、説明した方法と同じように、CATCHブロックの最後にRAISERRORを使用してエラーを呼び出し元に戻します。これにより、ストアドプロシージャ内の特定のエラーコードも処理できます。ここで

Answer 2

はtemplate I'm usingのサンプルです：

create procedure [usp_my_procedure_name] 
as 
begin 
    set nocount on; 
    declare @trancount int; 
    set @trancount = @@trancount; 
    begin try 
     if @trancount = 0 
      begin transaction 
     else 
      save transaction usp_my_procedure_name; 

     -- Do the actual work here 

lbexit: 
     if @trancount = 0 
      commit; 
    end try 
    begin catch 
     declare @error int, @message varchar(4000), @xstate int; 
     select @error = ERROR_NUMBER() 
       , @message = ERROR_MESSAGE() 
       , @xstate = XACT_STATE(); 
     if @xstate = -1 
      rollback; 
     if @xstate = 1 and @trancount = 0 
      rollback 
     if @xstate = 1 and @trancount > 0 
      rollback transaction usp_my_procedure_name; 

     raiserror ('usp_my_procedure_name: %d: %s', 11, 1, @error, @message) ; 
     return; 
    end catch 
end 

このテンプレートは、ネストされたトランザクションを処理し、各手順は、独自の作業をロールバックします（可能な場合）と、発信者の仕事をロールバックするかしない場合は、発信者が決めることができます。重要なことは、運命のトランザクションの可能性のためにXACT_STATEをチェックすることです。また、MSDNにはかなりのlengthy text on this very topicがあります。

TRY/CATCHとトランザクション管理に関して、あなたができることとできるべきことを変えることができる様々な問題もあります。分散トランザクションを使用していますか？リンクされたサーバーはありますか？いくつかのメンテナンスジョブに対して名前付きセーブポイント機能を復元する必要がありますか？元の例外コードにアクセスするには発信者が必要ですか？おそらく自動化された監視とアラート通知のために、例外の重大度を保持しますか？いくつかの状況ではいくつかのテンプレートとプラクティスが機能し、他のものではいくつかの機能が働いていることが重要です私が今までに投稿したテンプレートは、私のケースの大部分で良いと証明されました。