Dit is volledig voorspelbaar en wordt verwacht vanwege Datatypevoorrang
Hiervoor wordt de UI-kolom gewijzigd in decimaal(25,0)
where UI = 2011040773395012950010370
Deze klopt bijna. De rechterkant is varchar en is veranderd in nvarchar
where UI = '2011040773395012950010370'
Dit is de echt juiste versie waar beide typen hetzelfde zijn
where UI = N'2011040773395012950010370'
Er zijn fouten begonnen omdat de UI-kolom nu een waarde bevat die niet naar decimaal (25,0) kan worden CAST.
Enkele niet-gerelateerde opmerkingen:
- als je een index in de UI-kolom hebt, wordt deze in de eerste versie genegeerd vanwege de impliciete CAST die vereist is
- heb je unicode nodig om numerieke cijfers op te slaan? Er is een ernstige overhead met unicode-gegevenstypen in opslag en prestaties
- waarom niet
char(25). gebruiken ofnchar(25)is waarden zijn altijd vaste lengte? Uw zoekopdrachten gebruiken te veel geheugen als de optimizer gaat uit van een gemiddelde lengte van 128 tekens op basis vannvarchar(256)
Bewerken, na opmerking
Ga er niet vanuit "waarom werkt het soms" als je het niet weet dat het werkt
Voorbeelden:
- De waarde had kunnen worden verwijderd en later toegevoegd
- Een TOP-clausule of SET ROWCOUNT kan betekenen dat de overtredende waarde niet wordt bereikt
- De query is nooit uitgevoerd, dus het kan niet mislukken
- De fout wordt stilzwijgend genegeerd door een andere code?
Bewerk 2 voor hopelijk meer duidelijkheid
Chatten
gbn:
Willekeurig:
gbn
Zoals Tao vermeldt , is het belangrijk om te begrijpen dat een andere ongerelateerde vraag de zoekopdracht kan verbreken, zelfs als deze in orde is.