SQL Server tronque silencieusement les varchar dans les procédures stockées

C'est juste c'est .

Je n'ai jamais remarqué de problème car l'une de mes vérifications serait de m'assurer que mes paramètres correspondent à la longueur des colonnes de ma table. Dans le code client aussi. Personnellement, je m'attendrais à ce que SQL ne voie jamais de données trop longues. Si je voyais des données tronquées, la cause en serait évidente.

Si vous ressentez le besoin de varchar(max), méfiez-vous d'un énorme problème de performances en raison de la priorité des types de données. varchar(max) a une priorité plus élevée que varchar(n) (le plus long est le plus élevé). Ainsi, dans ce type de requête, vous obtiendrez une analyse et non une recherche et chaque valeur varchar(100) est CAST en varchar(max)

UPDATE ...WHERE varchar100column = @varcharmaxvalue

Modifier :

Il existe un élément Microsoft Connect ouvert concernant ce problème.

Et il mérite probablement d'être inclus dans les paramètres Strict d'Erland Sommarkog (et l'élément Connect correspondant).

Edit 2, après le commentaire de Martin :

DECLARE @sql VARCHAR(MAX), @nsql nVARCHAR(MAX);
SELECT @sql = 'B', @nsql = 'B'; 
SELECT 
   LEN(@sql), 
   LEN(@nsql), 
   DATALENGTH(@sql), 
   DATALENGTH(@nsql)
;

DECLARE @t table(c varchar(8000));
INSERT INTO @t values (replicate('A', 7500));

SELECT LEN(c) from @t;
SELECT 
   LEN(@sql + c), 
   LEN(@nsql + c), 
   DATALENGTH(@sql + c), 
   DATALENGTH(@nsql + c) 
FROM @t;