＃2008で遊んでみたいな...と思いながらも、手が出せずにいるこの頃です(^^;

さて、またもや失敗の話題です。今回の失敗は、CLRに関する事でした。

現在、Transact-SQLでカバー仕切れない処理などを、CLRを使ってコーディングしています。（データを正規表現を使ってSELECTさせたり、ストアドの実行結果を受けて外部プログラムをキックする、といった処理です）

＃CLRについては、賛否両論あるかと思いますが、どうしても方法が思いつかなかったので、利用しています...。

実際のアプリ/DBは、まだ開発段階なので、DBの停止も可能。βテスト分（という大層なものではないのですが）を公開するため、開発環境からDBをデアタッチして、コピーし、公開用のサーバにアタッチしました。（このDBには、CLR用のアセンブリも登録されています）

もちろん、公開用のSQL Serverも、CLRを有効に設定しておきました。

DBのアタッチは問題なく終了。関連するDBも、テスト環境で使っていたのと同じものを使い、動作的には全く同じに動くはずでした。

早速チェックを始めたのですが、普通のストアドも問題なく動いたので、「これで良いかな～」と、ひと安心。

ところが、同僚から『ストアドを実行するとエラーになっちゃうんですけど～』の声が...。

「なんで？ソースもデータもおんなじDBのはずなのに？？」と不審に思いながら、問題のストアドを実行すると、私の担当した部分でエラーが発生していました...。問題は、CLRで関数を実行している箇所で発生していました。

エラーメッセージは、この通り。

「アセンブリ ID 65648 をロード中に Microsoft .NET Framework でエラーが発生しました。
サーバーのリソースが不足しているか、PERMISSION_SET が EXTERNAL_ACCESS または UNSAFE 
に設定されていて、アセンブリが信頼されていない可能性があります。」

Management Studioで問題のアセンブリを参照すると、特にエラーのような表示は出ていません。関数も登録されています。（デタッチ/アタッチしただけなで）

でも、単純にCLRを単体で実行しても、同じエラーが....。

仕方なく、Visual Studioで、テスト公開用のDBに配布しなおしてみようとしたところ、これまたエラー。（開発用ではエラーになりません）

あわてて調べると、アタッチしたDBのTRUSTWORTHYプロパティが、Falseだったことが発覚。

この値は、ManagementStudioからは変更できなかったので、  ALTER DATABASE xxxxDB SET TRUSTWORTHY ON でTrueに変更したところ、配布OKになりました。

単純に、DBをアタッチするだけでは、TRUSTWORTHYの値は引き継がれないんですね.....。（どこのものとも分からないアセンブリをそのまま信頼するのは、確かに問題なんでしょうけれど）