Toon posts:

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

Pagina: 1
Acties:

Onderwerpen


  • Wijnbo
  • Registratie: december 2002
  • Laatst online: 22-09 14:56

Wijnbo

Electronica werkt op rook.

Topicstarter
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
  • Registratie: december 2001
  • Laatst online: 22:01

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Getallen en talstelsels FAQ

1010 = 10102
2010 = 101002

'10' = string 8)7

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]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • Wijnbo
  • Registratie: december 2002
  • Laatst online: 22-09 14:56

Wijnbo

Electronica werkt op rook.

Topicstarter
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
  • Registratie: december 2001
  • Laatst online: 21:50
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.

Whatever


  • PolarBear
  • Registratie: februari 2001
  • Niet online
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
  • Registratie: februari 2004
  • Laatst online: 24-09 13:16

NMe

Quia Ego Sic Dico.

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.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee