nvarchar(max) 切り捨て: 暗黙の変換トラップを解明する
SQL Server 2008 ストアド プロシージャの領域では、よく次のようなタスクに遭遇します。長く複雑なクエリを動的に生成します。このようなシナリオに対応するために、膨大な量のデータを保存できると宣伝されている、有名な nvarchar(max) データ型の変数を利用します。ただし、このような変数の値を取得しようとすると、よくある誤解が生じます。
nvarchar(max) 変数の値を出力すると、不思議なことにわずか 4000 文字に切り捨てられることがあります。この不可解な動作は、暗黙的な変換という隠れた落とし穴から生じています。
Unicode 値または nChar/nVarChar 値を連結すると、変数が nvarchar(max の場合でも) SQL Server は結果の文字列を密かに nVarChar(4000) に変換します。 ) データ型。この変換は、私たちには気づかれずに、クエリの早期切り捨てにつながります。
この暗黙的な変換トラップを回避するには、操作が行われる前に明示的に nvarchar(max) への連結を強制することが不可欠です。これは、連結の前に CAST('' as nVarChar(MAX)) を置くことで実現できます。空の文字列を nVarChar(MAX) にキャストし、クエリに連結することにより、クエリ構築プロセス全体を通じてより大きなデータ型を維持するように SQL Server に指示します。
次のコード スニペットを考えてみましょう:
SET @Query = CAST('' as nVarChar(MAX)) -- Force implicit conversion to nVarChar(MAX) + 'SELECT...' + '...' PRINT LEN(@Query) PRINT @Query
これで、@Query の値を出力すると、その完全な長さが正確に反映され、予期しない切り捨てが防止されます。この手法により、クエリがそのままの状態に保たれ、シームレスな実行と正確な結果が可能になります。
したがって、長いビルドを行う場合は常に、nvarchar(max) 変数を CAST('' as nVarChar(MAX)) で事前に連結することを忘れないでください。 、動的クエリ。このシンプルだが重要な手順により、暗黙的な変換の危険な落とし穴からあなたを救い、データの切り捨てを防ぎ、SQL Server コードを保護します。
以上がSQL Server 2008 で印刷すると、nvarchar(max) 変数が 4000 文字に切り捨てられるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。