text/char/varchar ではなく、sp_executesql が ntext/nchar/nvarchar パラメータとステートメントを必要とするのはなぜですか?
(すべてのステートメント/パラメーターを nvarchar として宣言することによって) この問題を回避する方法は理解していますが、Microsoft がこれを強制するのはなぜですか? 利点は何ですか?
text/char/varchar ではなく、sp_executesql が ntext/nchar/nvarchar パラメータとステートメントを必要とするのはなぜですか?
(すべてのステートメント/パラメーターを nvarchar として宣言することによって) この問題を回避する方法は理解していますが、Microsoft がこれを強制するのはなぜですか? 利点は何ですか?
これがその手順に固有の特定の理由で強制されているかどうかはわかりません。データ型にこだわるシステム ストアド プロシージャの別の例を次に示します。sp_trace_create.
nvarcharこれはパラメータに を要求するだけでなく@tracefile、パラメータ@maxfilesizeを「bigint」として渡す必要があり、常に正常にキャストできるリテラル整数を受け入れません。
これは失敗します
DECLARE @TraceID int
EXEC sp_trace_create @TraceID OUTPUT, 0, N'X:\Foo', 1, NULL
これは成功する
DECLARE @TraceID int
DECLARE @x bigint = 1
EXEC sp_trace_create @TraceID OUTPUT, 0, N'X:\Foo', @x, NULL
これらは両方とも、masterデータベース内でシステム拡張ストアド プロシージャとして表示されます。これらの拡張ストアド プロシージャの呼び出しメカニズムは、SQL Server がパラメーターを暗黙的にキャストしないように、通常のストアド プロシージャに使用されるものとは異なると思います。
sp_executesqlただし、そのように強制することは必ずしも悪いことではありませんnvarchar。動的 SQL で発生する可能性のある問題の 1 つは、文字列がサニタイズされた状態で提供され、変換がnvarchar強制されるとvarchar、SQL インジェクションの機会が開かれる可能性があることです。その例は、私の答え here にあります。