Това е напълно предвидимо и очаквано поради предимство на типа данни
За тази цел колоната на потребителския интерфейс ще бъде променена на decimal(25,0)
where UI = 2011040773395012950010370
Този е почти правилен. Дясната страна е varchar и се променя на nvarchar
where UI = '2011040773395012950010370'
Това е наистина правилна версия, където и двата типа са еднакви
where UI = N'2011040773395012950010370'
Грешките ще са започнали, защото колоната на потребителския интерфейс вече съдържа стойност, която няма да се преобразува в decimal(25,0).
Някои несвързани бележки:
- ако имате индекс в колоната на потребителския интерфейс, той ще бъде игнориран в първата версия поради необходимостта от косвен CAST
- имате ли нужда от уникод за съхраняване на цифрови цифри? Има сериозни разходи с уникод типове данни при съхранение и производителност
- защо не използвате
char(25)илиnchar(25)стойностите винаги ли са с фиксирана дължина? Вашите заявки използват твърде много паметта като оптимизатор приема средна дължина от 128 знака въз основа наnvarchar(256)
Редактиране, след коментар
Не предполагайте „защо работи понякога“, когато не знаете че работи
Примери:
- Стойността може да е била изтрита и добавена по-късно
- Клауза TOP или SET ROWCOUNT може да означава, че стойността на нарушението не е достигната
- Заявката никога не е изпълнявана, така че не може да се провали
- Грешката се игнорира мълчаливо от друг код?
Редактирайте 2 за надявам се повече яснота
Чат
gbn:
Произволно:
gbn
Както Тао споменава , важно е да разберете, че друг несвързан може да наруши заявката, дори ако този е ОК.
