4

SQL Server への接続が一時的に失われたことに対処しようとしているTransient Fault Handling Frameworkコードを調べました。重要なポイントが 1 つあります。これは、SQL 関連の問題 (構文エラーなど) と、SQL に関連しない問題 (接続がないなど) がある場合の両方でスローされます。SqlException

もちろん、後者のクラスの問題からのみ回復を試みる必要があります。コードが不正なクエリを実行する場合は、何も再試行せずに、すぐに失敗する必要があります。

SqlError.Numberフレームワークは、ハードコーディングされた膨大な値のセットを調べて比較することにより、これらのクラスを区別しようとします。これは多くの知識であり、この戦略に基づいたコードは、SQL Server の内部構造が変更されたら、間違いなくメンテナンスが必要になります。

SqlException.LineNumber代わりに使えるのではないかと思いましたか？MSDNによると、行番号は1から始まり、行番号0は行番号が適用されないことを意味するため、問題がSQLに関連していないことを意味すると思います。私はしばらくこれを試しました - 接続の問題LineNumberは常にゼロです。

SqlException.LineNumber例外が SQL クエリの問題によるものなのか、それとも接続の問題によるものなのかを特定するための信頼できる優れた方法を使用していますか?

4

1 に答える 1

0

例外が接続関連のエラーであることを示す指標として LineNumber プロパティを確実に使用できるとは思えません。LineNumber は、ストアド プロシージャ、トリガー、または関数の実行中にエラーが発生したときに設定されます。ただし、これらの項目以外のクエリや、LineNumber が 0 の SqlException を引き起こす可能性があるビューでもエラーが発生する可能性があります。最善の方法は、ハードコードされた値のセットと比較して Number プロパティを使用して説明した手法を使用することです。

于 2011-10-13T17:31:33.977 に答える