TRY CATCHでシステムエラーを検知できない

TRY CATCHをネストさせた状態で、
テーブルがドロップされていることを検知するにはどうすればよいでしょうか？

BEGIN TRY
　　★
　　BEGIN TRY
　　　　▲
　　END TRY
　　BEGIN CATCH
　　END CATCH
CATCH
END CATCH

としているときに、
★の位置だとテーブルのドロップはCATCH できるのですが
▲の位置だとテーブルのドロップはCATCH できないようですが、
テーブルがドロップされていることを検知するにはどうすればよいでしょうか？

No.1 回答者： osamuy 回答日時： 2012/04/29 07:49

例外で判断させるのは難しいのでは。

テーブルの存在確認かDDLトリガーを使用してみるとか。

この回答へのお礼

テーブル存在確認、DDLトリガー、調べてみます！
ありがとうございます！

お礼日時：2012/05/09 08:17

No.2 ベストアンサー 回答者： Siegrune 回答日時： 2012/05/02 00:29

関係ないかもしれませんが、

BEGIN TRY
　　★
　　BEGIN TRY
　　　　▲
　　END TRY
　　BEGIN CATCH
　　END CATCH
CATCH
↑ここにBEGINが必要では？
END CATCH

というのは置いておいて、

本当に、
★の位置だとテーブルのドロップはCATCH できるのですが
▲の位置だとテーブルのドロップはCATCH できないようですが、
となっているのでしょうか？

BEGIN TRY
　　★
　　BEGIN TRY
　　　　▲
　　END TRY
　　BEGIN CATCH
　　　　※１
　　END CATCH
BEGIN CATCH
※２
END CATCH
となっていたら、▲でテーブルがdropされていてエラーになったら、※２が実行されていると
思われるのですが。
★と▲両方に別のテーブルを使ったselect文を入れてみてそれぞれのテーブルがdropされた状態で
試してみられては、と思います。
理由
▲で使用しているテーブルがないときに、
　　BEGIN TRY
　　　　▲
　　END TRY
　　BEGIN CATCH
　　　　※１
　　END CATCH
がコンパイルエラーになるので、※２のほうのcatchが処理される。
と思いますが。
参考；
http://msdn.microsoft.com/ja-jp/library/ms175976 …
の
---引用---
TRY ブロック内の下位の実行レベル (たとえば、sp_executesql またはユーザー定義のストアド プロシージャを実行しているとき) でのコンパイル中またはステートメントレベルの再コンパイル中にエラーが発生した場合、そのエラーは TRY...CATCH 構造よりも下位のレベルで発生し、関連する CATCH ブロックによって処理されます。

次の例は、SELECT ステートメントによって生成されたオブジェクト名解決エラーが TRY…CATCH 構造でキャッチされず、同じ SELECT ステートメントをストアド プロシージャ内で実行した場合には CATCH ブロックでキャッチされることを示しています。
（以下例文が載っていますが省略）
---引用ここまで---

・・・マニュアルベースで実際には試していないですが。

この回答へのお礼

ありがとうございます
もう一度実行してみます！

お礼日時：2012/05/09 08:14