ストアドプロシージャの入力をサイレントで切り捨てないようにするにはどうすればよいですか？

Question

標準System.DataクラスDbConnectionとDbCommandを使用してC＃からSQL Serverに接続し、VARCHARまたはNVARCHARパラメータを入力として使用するストアドプロシージャが多数あります。パラメータの最大長よりも長い文字列がそのパラメータに値として渡されると、SQL ServerとC＃アプリケーションのどちらもエラーまたは警告をスローしませんでした。代わりに、値は静かにパラメータの最大長に切り捨てられます。ストアドプロシージャの入力はタイプVARCHAR(10)であり、我々は'U R PRETTY STUPID'に渡す場合

だから、たとえば、ストアドプロシージャは、私たちが言うことを意味したものは非常にいいが、完全ではありません'U R PRETTY'などの入力を受け付けます。

これらの切り捨てを検出するために私が過去に行ったことと、others have likewise suggestedは、パラメータ入力の長さを必要以上に1文字大きくし、入力の長さが新しい最大長と等しいかどうかを確認することです。したがって、上記の例では私の入力はVARCHAR(11)になり、長さ11の入力をチェックします。長さ11以上の入力はこのチェックで捕捉されます。これは機能しますが、間違っていると感じます。理想的には、データアクセス層はこれらの問題を自動的に検出します。

提供されたストアドプロシージャの入力が許可された時間を超えていることを検出する方法がありますか？ DbCommandはすでに入力の長さの制限を認識していないはずですか？

また、好奇心の問題として、入力を黙って切り捨てる原因は何ですか？

Answer 1

すべての変数とパラメータに対して、VARCHAR(8000),NVARCHAR(4000)、さらにはN/VARCHAR(MAX)を使用してください。このようにして、@変数と@パラメータを割り当てるときに切り捨てを心配する必要はありません。切り捨ては、実際のデータ書き込み（挿入または更新）時に発生しますが、サイレントではなく、ハードエラーを引き起こします。また、ストアドプロシージャコードがスキーマの変更（列の長さの変更、コードはまだ有効）で変更する必要がないという利点が追加されます。また、一貫したパラメータの長さを使用することで、より良いプランキャッシュ動作が得られます。How Data Access Code Affects Database Performanceを参照してください。

@ variables/@ parametersにMAXタイプを使用した場合、パフォーマンスがわずかに低下することに注意してください。Performance comparison of varchar(max) vs. varchar(N)を参照してください。