問題タブ [sqlclr]

私は、SQL Server 2005/2008 で利用できるいくつかの新しいテクノロジを調査しています。私のアプリケーションのほとんどは C# で記述されており、通常はデータベース コンポーネントが含まれています。私が Google で見つけたもののほとんどは、「これが CLR UDT のセットアップ方法です」という基本的なものです。それらの実際のアプリケーションと使用について、いくつかの一般的な質問があります。

• CLR でホストされる UDT は、アプリケーションで一般的に使用されていますか? 大規模または小規模
• それらを使用する際にパフォーマンスの問題はありますか?
• DBA は通常、組み込み型のみを使用することを好みますか?

オブジェクトをテーブルに詰め込む方法のように思えます。それらの使用のために解決策を単純化した問題の実際の範囲は最小限であると想定するのは正しいですか?

私はそれがサポートされていないことを知っています。しかし、SQL テーブル値関数内に WCF クライアントが必要です。

(一見) 正しいアセンブリを登録しましたが、クライアントを実行すると、WCF エラーが発生します。

Sql Server の外部でのテストはうまくいっているようですが、WCF クライアントが TCP 接続を確立しようとしている様子さえ見られません。

私は両方とも初めてなので、これがWCFまたはSQL CLRの問題であるかどうかはわかりません.....

編集:必要な System.ServiceModel とその多数のアセンブリが、精査された Sql CLR リストの外にあることを理解しています。でも、

「サポートされていないライブラリは、マネージ ストアド プロシージャ、トリガー、ユーザー定義関数、ユーザー定義型、およびユーザー定義集計から引き続き呼び出すことができます。サポートされていないライブラリは、最初に CREATE ASSEMBLY ステートメントを使用して SQL Server データベースに登録する必要があります。コードで使用する前に. サポートされていないライブラリが登録され、サーバー上で実行されている場合は、セキュリティと信頼性を確認してテストする必要があります."

に相当するものはありますか

これはCLR（C＃）コードから呼び出すことができますか？

関数にデバッグ情報を出力しようとしています。これはリモートサーバーであるため、VSデバッガーを実行できません。

ありがとう！

tsqlからoleオブジェクトを呼び出すことに固有の問題はありますか？ストアドプロシージャだけを使用して解決したいという問題が発生しましたが、clrベースの言語で記述するのではなく、oleオブジェクトを使用する場合に心配する必要があることはありますか？

SQLCLRルーチン内からSQLServerエラーイベント（RAISERRORと同様）をどのように発生させますか？

これは状況です：

Trigger.dll と Trigger.XmlSerializer.dll があります。

CREATE ASSEMBLY を使用して、MSSQL に登録します。

今、私は両方の新しいバージョンをコンパイルしました。

ALTER ASSEMBLY を使用して更新したいのですが、一度に 1 つしか更新できません。依存関係のあるものを更新しようとすると、エラーが発生します。これを行うためのトリックは何ですか？

すべてのトリガーなどを削除する必要があり、データベースのダウンタイムがあるため、削除して再作成したくありません。

Table-Valued-Functionの非常に簡単なテストを含むSqlServerプロジェクトがあります：-

接続のオープンは現在コメントアウトされていることに注意してください。デプロイしたら、SQLで次のように実行できます：-

すべて正常に動作します。

今、私はコメントを外し、con.open()それは次のように失敗します：-

このコンテキストでは、データアクセスは許可されていません。コンテキストは、DataAccessKind.ReadまたはSystemDataAccessKind.Readでマークされていない関数またはメソッドであるか、テーブル値関数のFillRowメソッドからデータを取得するためのコールバックであるか、UDT検証メソッドです。

問題が何であるかわかりません。TestConn関数がありDataAccessKind.Readます。

このエラーが発生する他の理由を知っている人はいますか？

Sql Server 2005 で UDF からいくつかの CLR コードにアクセスすることを検討しています。

CLR コードでスローされた未処理の例外がサーバーをダウンさせるという話を聞いたことがあります。

明らかに、私の関数には try-catch ブロックが含まれます。ただし、特定の例外 (stackoverflow) はキャッチをスキップできます。

CLR コードがサーバーをダウンさせるリスクを完全に排除 (または最小化) できる一連のガイドラインを持っている人はいますか?

既存の C# コードを CLR ストアド プロシージャに変換しようとしています。使用する明白な接続文字列は、コンテキスト接続 ("context connection = true") です。

私が直面している問題は、この接続タイプでは明らかに機能しないことがいくつかあります。最新のことは、SqlConnection.GetSchema メソッドが失敗することです。エラーは、コンテキスト接続では使用できないことを示しているだけです。コンテキスト接続で機能しないもののリストはどこかにありますか?