2012-02-15 22 views
0

私は最近、JSONシリアライゼーションを使用してパラメータ配列をSQL Serverストアドプロシージャに渡し、デシリアライズされ、必要な値が抽出されるチームに参加しました。つまり、各ストアドプロシージャに '@Parameters 'VARCHAR(MAX)型のパラメータです。コマンドを作成して実行するフレームワークはC#で記述され、標準の.NETタイプ(SqlCommand、SQlParameterなど)を使用します。JSONシリアライゼーションと.NET SQLのパラメータ

シリアル化されたコンテンツの長さが、ストアドプロシージャが正しく行われていないしきい値例外は発生しません。何も起こらないようです。 SQLプロファイラの実行SQL Serverでストアドプロシージャを実行しようとしていないことがわかりました。

例: 1つのケースでは、わずか8つのプロパティがシリアル化されているタイプのインスタンスがわずか30個あります。シリアライゼーションは成功し、値はSqlCommandのパラメータコレクション内のsqlパラメータに割り当てられます(パラメータは1つだけです)。コマンドは実行されますが、何も起こりません。あるタイプのオカレンスが少ない場合、それは成功します。成功しなかった場合、例外は発生していません。

使用: SQL Server 2008 C#.NET 4.0 JSONシリアライゼーションはNewtonsoftによって提供されています。 コード内のSqlParameterは、varchar maxとして作成されます。 クライアントサーバーアーキテクチャ - 仲介サービスはありません。

SqlCommandでsqlパラメータとして渡されるJSON直列化された値の制限を知っている人や、この現象の原因となる考え方はありますか?

+0

サンプル@パラメータ値を入力できますか? –

+0

問題は、正しく形成されたコンテンツ自体ではなく、コンテンツの長さにあります。私は実際に、Jsonの直列化された値をSQLパラメータとして渡すときにサイズの制限を認識しているかどうかを調べていました。 – Trev

答えて

0

私の場合は何が起こっているのか分かりました。 SQLパラメータの値の逐次化とは何の関係もありませんでした。私は、プロシージャが最終的に実行されるのに十分長い時間(私の場合は5〜7分)待っていました。

ストアドプロシージャには、関心のあるレコードを抽出するためにカーソルが使用されています(これはバッチ更新プロシージャです)。このカーソルはCLR関数を呼び出して、必要な値ごとにJsonを逆シリアル化します。デシリアライズされたデータを一時テーブルに挿入してカーソルで使用することにより、「問題」が解決されました。

関連する問題