Esto es completamente predecible y esperado debido a la precedencia del tipo de datos
Para esto, la columna de la interfaz de usuario se cambiará a decimal (25,0)
where UI = 2011040773395012950010370
Este es casi correcto. El lado derecho es varchar y se cambia a nvarchar
where UI = '2011040773395012950010370'
Este es el realmente versión correcta donde ambos tipos son iguales
where UI = N'2011040773395012950010370'
Los errores habrán comenzado porque la columna de la interfaz de usuario ahora contiene un valor que no se CAST a decimal (25,0).
Algunas notas no relacionadas:
- si tiene un índice en la columna de la interfaz de usuario, se ignorará en la primera versión debido al CAST implícito requerido
- ¿Necesita unicode para almacenar dígitos numéricos? Hay una sobrecarga grave con tipos de datos Unicode en almacenamiento y rendimiento
- por qué no usar
char(25)onchar(25)¿Los valores son siempre de longitud fija? Sus consultas usan demasiado memoria como el optimizador asume una longitud promedio de 128 caracteres segúnnvarchar(256)
Editar, después del comentario
No asumas "por qué funciona a veces" cuando no sabes que si funciona
Ejemplos:
- El valor podría haberse eliminado y luego agregado más tarde
- Una cláusula TOP o SET ROWCOUNT podría significar que no se alcanza el valor ofensivo
- La consulta nunca se ejecutó, por lo que no podía fallar
- ¿El error es ignorado silenciosamente por algún otro código?
Edición 2 para obtener más claridad con suerte
Chatear
GBN:
Aleatorio:
GBN
Como menciona Tao , es importante comprender que otra consulta no relacionada puede romper la consulta incluso si esta está bien.
