[T-SQL/MSSQL] Afdwingen typesafety, kan dat?

[Wijnbo]

Probleem:

Kolom met 10 & 20 smallint waardes gerefactored naar een bit kolom.

* Wijnbo dacht : Mooi, nu knallen ook al mijn stored procedures er uit waar de constructie WHERE kolom = 10 in voorkomt.

Niet dus.

Waarom gaat dit niet fout? Kun je dit instellen ergens? En, nog belangrijker : Waarom gaat WHERE kolom = '10' wel fout?

MSSQL kan toch zelf wel snappen dat je van 10 of 20 nooit een bit kunt bouwen?

edit: WHERE kolom = '10' gaat goed, WHERE kolom = 'blaat' gaat fout

[ Voor 8% gewijzigd door Wijnbo op 03-11-2010 08:45 ]

[RobIII]

Getallen en talstelsels FAQ

10₁₀ = 1010₂
20₁₀ = 10100₂

'10' = string

Ofwel: There are 10 kinds of people in the world — those who understand binary and those who don't.

Wijnbo schreef op dinsdag 02 november 2010 @ 08:09:
MSSQL kan toch zelf wel snappen dat je van 10 of 20 nooit een bit kunt bouwen?

Nee, jij moet snappen dat 10 of 20 gewoon een decimale representatie van een waarde is die je net zo goed in hexadecimale of binaire notatie kunt schrijven
Als jij de kolommen naar een bit kolom hebt gerefactored dan is de waarde dus 0 of 1; dat je daar een vergelijking mee uit voert met 10/20/whatever boeit niet; dat de resultaten niet zijn zoals je ze zou verwachten is andere koek (en ligt aan jezelf).

[ Voor 78% gewijzigd door RobIII op 02-11-2010 10:45 ]

[Wijnbo]

Dank je voor je reactie, maar waarom knalt ie er wel uit op WHERE kolom = 'a' ?

compiled wel :

WHERE kolom = 5
WHERE kolom = 10
WHERE kolom = '10'

compiled niet:

WHERE kolom 'a'

Waarom besluit SQL zelf dat het getal 5 gelijk is aan een binaire nul?
Waarom besluit SQL zelf dat het getal 10 gelijk is aan een binaire nul?
Waarom besluit SQL zelf dat de string '1' gelijk is aan een binaire nul?
Waarom besluit SQL zelf dat de string 'a' niet gelijk kan worden gesteld aan een binaire nul?

Tuurlijk snap ik dat je 5 als 101 kunt schrijven, en dat dat niet gelijk is aan 1. Maar waarom zit er geen "check" in dat je altijd of een 0 of een 1 moet aanleveren? Waarom probeert sql van een string wel eerst een getal te maken?

Daar ontgaat mij de logica.

[ Voor 17% gewijzigd door Wijnbo op 03-11-2010 08:44 ]

[DigiK-oz]

Een bit kolom is in feite gewoon een numerieke kolom met scherpe restricties vwb de waarden die er in passen. Dus als jij in de where een string zet, probeert MSSQL die string naar numeriek te converteren om jouw query uit te voeren. Dit gaat goed bij '10', en natuurlijk niet bij 'a',

Vervolgens wordt dus gekeken of jouw bit veld gelijk is aan de waarde in jouw query. Dus moet de waarde in jouw query worden geconverteerd naar het juiste datatype.(bit), De documentatie zegt daar over :

Converting to bit Data

Converting to bit promotes any nonzero value to 1.

[PolarBear]

Of je leest de documentatie gewoon een keer.

When converting character or binary expressions (char, nchar, nvarchar, varchar, binary, or varbinary) to an expression of a different data type, data can be truncated, only partially displayed, or an error is returned because the result is too short to display. Conversions to char, varchar, nchar, nvarchar, binary, and varbinary are truncated, except for the conversions shown in this table.

[NMe]

Wijnbo schreef op woensdag 03 november 2010 @ 08:41:
Dank je voor je reactie, maar waarom knalt ie er wel uit op WHERE kolom = 'a' ?

compiled wel :

WHERE kolom = 5
WHERE kolom = 10
WHERE kolom = '10'

Daar staat: WHERE kolom = 101 (binair) en twee keer WHERE kolom = 1010. T/SQL doet daar volgens de hierboven geposte tabel netjes een impliciete conversie naar bits. Nou weet ik niet of T-SQL nu alles boven het least significant bit negeert of dat alles dat niet 0 is als 1 wordt gezien, maar daar zit vast logica achter.

compiled niet:

WHERE kolom 'a'

Tuurlijk niet, want hier is een impliciete cast naar iets numerieks onmogelijk. '0xA' zou misschien wel werken, afhankelijk van je database-engine, want dat is gewoon interpreteerbaar als 10.

Waarom besluit SQL zelf dat het getal 5 gelijk is aan een binaire nul?
Waarom besluit SQL zelf dat het getal 10 gelijk is aan een binaire nul?
Waarom besluit SQL zelf dat de string '1' gelijk is aan een binaire nul?

Van deze drie voorbeelden kan ik me hooguit voorstellen dat 10 als 0 gezien wordt vanwege de LSB. De andere twee zouden als 1 gezien moeten worden volgens mijn beiden mogelijkheden hierboven.

Tuurlijk snap ik dat je 5 als 101 kunt schrijven, en dat dat niet gelijk is aan 1. Maar waarom zit er geen "check" in dat je altijd of een 0 of een 1 moet aanleveren? Waarom probeert sql van een string wel eerst een getal te maken?

Garbage in, garbage out. Je database kan niet raden of jij nou wel of niet een impliciete cast wil.