Ceci est tout à fait prévisible et attendu en raison de la la priorité des types de données
Pour cela, la colonne UI sera remplacée par decimal(25,0)
where UI = 2011040773395012950010370
Celui-ci est presque correct. Le côté droit est varchar et est changé en nvarchar
where UI = '2011040773395012950010370'
C'est le vraiment version correcte où les deux types sont identiques
where UI = N'2011040773395012950010370'
Les erreurs auront commencé car la colonne UI contient maintenant une valeur qui ne sera pas convertie en décimal (25,0).
Quelques notes sans rapport :
- si vous avez un index sur la colonne UI, il sera ignoré dans la première version en raison du CAST implicite requis
- Avez-vous besoin d'Unicode pour stocker des chiffres ? Il y a un un surcoût sérieux avec des types de données Unicode dans le stockage et les performances
- pourquoi ne pas utiliser
char(25)ounchar(25)est-ce que les valeurs sont toujours de longueur fixe ? Vos requêtes utilisent trop suppose une longueur moyenne de 128 caractères basée surnvarchar(256)
Modifier, après commentaire
Ne présumez pas "pourquoi ça marche parfois" quand vous ne savez pas que ça marche
Exemples :
- La valeur aurait pu être supprimée puis ajoutée ultérieurement
- Une clause TOP ou SET ROWCOUNT peut signifier que la valeur incriminée n'est pas atteinte
- La requête n'a jamais été exécutée, elle ne pouvait donc pas échouer
- L'erreur est silencieusement ignorée par un autre code ?
Modifier 2 pour plus de clarté, espérons-le
Discuter
gbn :
Aléatoire :
gbn
Comme le mentionne Tao , il est important de comprendre qu'un autre non lié peut casser la requête même si celui-ci est OK.
