Podivný problém s převodem typu SQL Server

To je zcela předvídatelné a očekávané z důvodu Priority datových typů

Za tímto účelem se sloupec uživatelského rozhraní změní na decimal(25,0)

where UI = 2011040773395012950010370

Tento je téměř správný. Pravá strana je varchar a je změněna na nvarchar

where UI = '2011040773395012950010370'

Toto je skutečně správná verze, kde jsou oba typy stejné

where UI = N'2011040773395012950010370'

Chyby začaly, protože sloupec uživatelského rozhraní nyní obsahuje hodnotu, která se nepřenáší na desítkové číslo (25,0).

Některé nesouvisející poznámky:

• pokud máte index ve sloupci uživatelského rozhraní, bude v první verzi ignorován z důvodu implicitního požadavku CAST
• potřebujete k ukládání číselných číslic unicode? Existuje vážná režie s datovými typy Unicode v úložišti a výkonu
• proč nepoužít char(25) nebo nchar(25) jsou hodnoty vždy pevné délky? Vaše dotazy příliš využívají paměť jako optimalizátor předpokládá průměrnou délku 128 znaků na základě nvarchar(256)

Upravit po komentáři

Nepředpokládejte „proč to někdy funguje“, když nevíte že to funguje

Příklady:

• Hodnotu bylo možné smazat a přidat později
• Klauzule TOP nebo SET ROWCOUNT může znamenat, že nebylo dosaženo problematické hodnoty
• Dotaz nebyl nikdy spuštěn, takže nemohl selhat
• Je chyba tiše ignorována nějakým jiným kódem?

Upravte 2 pro snad větší přehlednost

Chat

gbn:

Náhodně:

gbn

Jak zmiňuje Tao , je důležité pochopit, že jiný nesouvisející dotaz může přerušit dotaz, i když je tento v pořádku.