Pourquoi ma variable NVARCHAR(MAX) est-elle tronquée dans le SQL dynamique de SQL Server ?

Comprendre le problème de troncature avec NVARCHAR(MAX)

Lors de la création de requêtes SQL dynamiques, il est crucial de s'assurer que les opérations de concaténation de chaînes n'aboutissent pas en troncature inattendue. Dans ce scénario, le problème rencontré avec @Query étant tronqué à 4 000 caractères malgré son type de données NVARCHAR(MAX) mérite une enquête.

Malheurs de conversion implicite

Le coupable réside en conversion implicite. Lors de la concaténation de chaînes contenant des valeurs Unicode/nChar/nVarChar, SQL Server les convertit automatiquement en type de données plus restrictif nVarChar(4000). Cette conversion est effectuée avant toute conversion explicite en NVARCHAR(MAX) affectée à la variable @Query.

Une solution simple pour éviter la troncature

Le remède est de forcer explicitement la conversion en nVarChar(MAX) avant toute opération de concaténation. En initialisant @Query avec CAST('' as nVarChar(MAX)), les opérations de concaténation ultérieures s'ajouteront à une chaîne déjà définie comme capacité maximale, empêchant ainsi la troncature.

Surpasser la limite de 8 000 caractères

Si la limite maximale est de 8000 caractères, cela indique une conversion en VarChar(8000) en raison de l'absence de Données Unicode. De même, un transtypage de type explicite peut être utilisé pour forcer la conversion en nVarChar(MAX).

Contraintes de chaîne littérale

Il est important de noter que même avec NVARCHAR(MAX) , une seule chaîne littérale ininterrompue ne peut pas dépasser 4 000 (ou 8 000 pour VarChar) caractères. Pour éviter la troncature, ces chaînes doivent être divisées par concaténation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!