[ASP MSSQL] datum wordt standaard 1-1-1900 ipv nx

[muis|IA]

Ik heb een MSSQL db met daarin een aantal velden waarvan één een date/time veld. Als ik iemand geen geboortedatum heeft ingevuld moet er in dit date/time veld ook nx worden ingevuld.
Maar toch wordt deze dan 1-1-1900. Als er wel een datum is ingevuld komt deze perfect in de db te staan.
Ik kan me niet herinneren dat ik een standaard waarde heb meegegeven aan de tabel bij het maken van de tabel.
Weet iemand misschien waar die 1-1-1900 vandaankomt?

[daaan]

mischien dat je NOT NULL oid hebt gedaan, dat ie zelf een datumpje verzint.

[Verwijderd]

Insert je niet perongeluk een 0 ipv een NULL value in je tabel als iemand geen datum invoerd?

[muis|IA]

ik insert als het goed is helemaal nx
ik insert de waarde van de variabele gebdatum en die heb ik boven zo neergezet -> gebdatum = "" en ik heb ook gebdatum = NULL geprobeerd maar bij allebei zelfde resultaat

[Verwijderd]

Waar komt die 1-1-1900 eigenlijk terug? in je (vb?) applicatie of als je zelf in de query analyzer een select op je tabel doet? wat doet ie als je handmatig in je query analyzer een insert doet?

[mulder]

Op donderdag 21 februari 2002 10:35 schreef muis het volgende:
ik insert als het goed is helemaal nx
ik insert de waarde van de variabele gebdatum en die heb ik boven zo neergezet -> gebdatum = "" en ik heb ook gebdatum = NULL geprobeerd maar bij allebei zelfde resultaat

Volgens mij bedoelen ze hierboven je default waarde in je SQL db

[muis|IA]

voor zover ik weet heb ik nx ingevuld bij een standaard waarde. Maar hoe kan ik daar achter komen?

[Verwijderd]

'0' in een datumveld zetten resulteert in de datum 1/1/1900 op een SQLServer.

[muis|IA]

ik heb de query zelf nog ff bekeken maar als ik dus geen gedatum invul en die dus leeg is -> '' dan krijg ik dus 1-1-1900. Het zal idd wel de standaard waarde zijn.
Maar heeft iemand enig idee hoe ik deze verander?

Alter table tbl_blaat alter column geboortedatum datetime NULL .... en dan?

[Verwijderd]

Wat dacht je van een default value?

Het ding MOET een waarde hebben, NULL of iets anders. Het is IMHO bad database design als je NULL fields toelaat, want dit levert errors op in code die je met onnodige code weer moet afvangen. Dus blijft een initiele waarde over. '0' is dan OK. Eventueel een bitfield ernaast dat aangeeft of de waarde gezet is of niet (dwz GeboorteDatumIsValid bit)

Besluit je om NULL fields toe te laten dan zou ik het NULL laten en in je retrieval query de ISNULL() functie gebruiken om NULL fields naar '0' om te zetten.

[Annie]

Op donderdag 21 februari 2002 12:00 schreef Otis o.a.:
Het is IMHO bad database design als je NULL fields toelaat, want dit levert errors op in code die je met onnodige code weer moet afvangen.

Dit getuigt meer van een onbegrip wat de 'waarde' NULL betekend dan van slecht db-design, imho.

[Verwijderd]

Op donderdag 21 februari 2002 13:23 schreef Annie het volgende:

[..]


Dit getuigt meer van een onbegrip wat de 'waarde' NULL betekend dan van slecht db-design, imho.

heh neu
Het gaat om het feit dat bij een retrieval van data uit de tabel, de ontvangde partij van de dataset/recordset er vanuit mag gaan dat de data er is en niet dmv het testen op 'NULL' moet kijken of er data is of niet.

NULL columns worden door sommige designers gebruikt voor het aangeven van 'non-mandatory' data, maar eerlijk gezegd ben je een stuk robuuster bezig door alle columns NOT NULL te maken en default values te definieren. Zodoende hoef je niet alle columns te vullen, maar is bij een dataretrieval wel elke column in je data/recordset gevuld met een waarde en hoeft de ontvangende partij niet te kloten met testcode of een field een waarde heeft. (die vroeg nl. om data, niet om NULL values, en verwacht van de supporting layer waar hij die data aan vraagt of dat verzorgt kan worden. Dat er NULL values in staan is niet het probleem van de ontvanger.)

[Verwijderd]

Op donderdag 21 februari 2002 14:05 schreef Otis het volgende:
maar is bij een dataretrieval wel elke column in je data/recordset gevuld met een waarde en hoeft de ontvangende partij niet te kloten met testcode of een field een waarde heeft.

Jij vind dus een veld vullen met een default dummy waarde en het zetten van 'n extra bitfield minder werk dan het simpel weg testen op een NULL value?

[mulder]

Ik test ook liever op NULL, dan weet ik zeker dat een waarde helemaal niet gezet is, en dus niet hoef te checken of op 0 of op "1-1-1900", wat volgens mij een stuk onbetrouwbaarder is. En een extra veldje om te checken of er in een ander veld een waarde staat? Lijkt me niet.

EDIT: Want je kan juist prima met code controleren of een waarde NULL is. Errors komen dan door slecht coderen.

[Crazy D]

Op donderdag 21 februari 2002 14:05 schreef Otis het volgende:
en hoeft de ontvangende partij niet te kloten met testcode of een field een waarde heeft. (die vroeg nl. om data, niet om NULL values, en verwacht van de supporting layer waar hij die data aan vraagt of dat verzorgt kan worden. Dat er NULL values in staan is niet het probleem van de ontvanger.)

Ben ik op zich wel met je eens, alleen in het geval van een datum, wat wil je er anders van maken? Je zou overigens in de query natuurlijk gewoon op isnull kunnen checken, en 'm een lege waarde of 0-0-0000 terug laten geven of zo, beetje afhankelijk van wat er met de data moet worden gedaan.

[Annie]

Op donderdag 21 februari 2002 14:05 schreef Otis het volgende:
NULL columns worden door sommige designers gebruikt voor het aangeven van 'non-mandatory' data, maar eerlijk gezegd ben je een stuk robuuster bezig door alle columns NOT NULL te maken en default values te definieren.

Prima dat de ontvangende partij niet hoeft te weten dat de waarde NULL is, maar dan moet je dus in je applicatie laag checken op NULL en deze evt. omzetten in een 'leukere' waarde, imho.
In de database hoort de data te staan die daar thuishoort en niet 'vervuilde data' alleen maar omdat dat handiger is voor de gebruikers.

Bijvoorbeeld:
In de database staat 0 bij het salaris van Jan.
Betekend dat dan dat Jan zijn salaris niet heeft ingevuld (en dus een defaultwaarde krijgt) of dat hij echt niks krijgt per maand?
En wat als je AVG(salaris) wil doen?

Op donderdag 21 februari 2002 14:05 schreef Otis het volgende:
(die vroeg nl. om data, niet om NULL values, ....

NULL is ook data

[Verwijderd]

Op donderdag 21 februari 2002 14:13 schreef Yarvieh het volgende:
[..]
Jij vind dus een veld vullen met een default dummy waarde en het zetten van 'n extra bitfield minder werk dan het simpel weg testen op een NULL value?

Ja. Dit komt op hetzelfde neer als bv in C/C++:

code:

SSomeStruct *pPointer;

// some function
pPointer = SomeFunctionReturningStruct();

// ... some code

// freeing memory
free(pPointer);
// ...some other code
// testing if pPointer is freed?
if(pPointer)
{
       // ...
}

Dit is brakke code. Niet alle C runtimes zet namelijk de pointer op NULL bij de free. Er een flag voor gebruiken, DAT je de pointer/mem hebt gefreed is beter.

Je test op een NULL value in een databaseveld om welke reden? Een semantische waarde geven aan de inhoud van dat veld. Echter, dit is LOGISCHER door te testen op een boolean veld dat aangeeft of het veld valid is of niet, dan te testen op een NULL value. Sommige talen ondersteunen niet het testen op NULL values, wat je opvangt door het bitveld.

Logisch met je data omgaan, daar gaat het hier over. Indirect semantische waarde hechten aan NULL values lijkt me minder logisch (en met mij veel database designers) dan het testen op een field dat daarvoor speciaal is gecreeerd.

[Verwijderd]

Op donderdag 21 februari 2002 15:44 schreef Annie het volgende:

Prima dat de ontvangende partij niet hoeft te weten dat de

NULL is ook data

Helemaal mee eens...

[Verwijderd]

Otis, wil je dan voor elk veld in een database een extra veld opnemen om aan te geven dat deze is ingevuld

Lijkt me dat je hierdoor wel heel veel overhead in je db krijgt.

[Verwijderd]

Kortom je voegt inrelevante velden aan je database toe omdat je van menig bent dat de software waarmee je de database benaderd niet in staat is met NULL values om te gaan

[Verwijderd]

Op donderdag 21 februari 2002 15:44 schreef Annie het volgende:
[..]
Prima dat de ontvangende partij niet hoeft te weten dat de waarde NULL is, maar dan moet je dus in je applicatie laag checken op NULL en deze evt. omzetten in een 'leukere' waarde, imho.

Waarom moet ik checken op een NULL waarde? Ik moet ALLEEN checken op null values om errors te voorkomen.

In de database hoort de data te staan die daar thuishoort en niet 'vervuilde data' alleen maar omdat dat handiger is voor de gebruikers.

Het is niet aan de database om te bepalen wat de semantische waarde is van data. De database slaat data op, verder niks.

Bijvoorbeeld:
In de database staat 0 bij het salaris van Jan.
Betekend dat dan dat Jan zijn salaris niet heeft ingevuld (en dus een defaultwaarde krijgt) of dat hij echt niks krijgt per maand?
En wat als je AVG(salaris) wil doen?

AVG over non-mandatory fields, wat zegt dat? Ik zou voor een non-mandatory field een bitfield opnemen of de waarde geldig is of niet. Dat veld vertelt een functie of de waarde geldig genoemd kan worden of niet. Verder niks.

Wil je per se aggregates draaien over non-mandatory fields, kun je daar altijd faciliteiten voor treffen.

NULL is ook data

Nee, NULL is geen data, maar een 'leeg' aanduiding. 0 is data, 'NULL' niet. Maar dat is een academische discussie ala 'C++' is wel/niet OO.

[Verwijderd]

Op donderdag 21 februari 2002 16:08 schreef Otis het volgende:
Waarom moet ik checken op een NULL waarde? Ik moet ALLEEN checken op null values om errors te voorkomen.

voorbeeld:

code:

Select * from tblWoningen where verkoopdatum is NULL

[mulder]

Op donderdag 21 februari 2002 15:58 schreef Otis het volgende:

Sommige talen ondersteunen niet het testen op NULL values, wat je opvangt door het bitveld.

Welke taal niet? Zie nu wel wat meer in dat bitveld btw, maar zo het niet snel gebruiken. Denk trouwens dat in dit geval (de meeste gevallen) je wil weten welke datums NOT NULL zijn, dus niet ge-(re)set zijn. Resetten van die datum, denk het niet snel.

[Verwijderd]

Op donderdag 21 februari 2002 16:08 schreef Otis het volgende:

[..]

Nee, NULL is geen data, maar een 'leeg' aanduiding. 0 is data, 'NULL' niet. Maar dat is een academische discussie ala 'C++' is wel/niet OO.

Helemaal mee eens. 'NULL' geeft aan dat er geen data is. Net zoals wit (of zwart) geen kleur is. Daarom is het ideaal om aan te geven dat er nog geen data voor het desbetreffende veld aanwezig is. (en niet door het te vullen met een default waarde)

[Verwijderd]

Op donderdag 21 februari 2002 16:02 schreef r-e-m het volgende:
Otis, wil je dan voor elk veld in een database een extra veld opnemen om aan te geven dat deze is ingevuld
Lijkt me dat je hierdoor wel heel veel overhead in je db krijgt.

Nee, alleen voor non-mandatory fields. Je weet wel, die velden die volgen uit een 0:n relatie. Veelal zijn velden in een table echter mandatory (1:1 of 1:n relaties).

Maar dit is een zeurdiscussie ala dat je pointers moet testen op NULL versus een boolean testen. De nitwitts die grienen om elke regel code zullen pointervalidatie code bouwen op basis van NULL-tests, mensen die snappen dat je solide code moet maken, bouwen pointervalidatie code op basis van boolean tests.

Als ik een recordset terugkrijg en ik moet velden vullen in een client wil ik dat in een kleine loop doen die niet vergeven is van af en toe een NULL test want o jee, anders crasht de code. Die code is nl. leesbaarder wanneer je test op velden die validiteit aangeven over andere velden. Oftewel semantische meerwaarde geven aan je records.

Maar iedereen moet maar doen wat hij/zij het beste vindt. Mijn databases hebben nooit NULL values en veel prof. database designers denken er net zo over. Je komt er wel op terug, echt

[Verwijderd]

en veel prof. database designers denken er net zo over

Waar haal je dit vandaan..

[Verwijderd]

Op donderdag 21 februari 2002 16:12 schreef Don Facundo het volgende:
[..]
Welke taal niet? Zie nu wel wat meer in dat bitveld btw, maar zo het niet snel gebruiken. Denk trouwens dat in dit geval (de meeste gevallen) je wil weten welke datums NOT NULL zijn, dus niet ge-(re)set zijn. Resetten van die datum, denk het niet snel.

VB had lange tijd geen IsNull functie. Je moest dat doen door waarde uit dat veld te halen, en dan in een errorhandler kijken welke error je kreeg en dan resumen. Net zoals je dat deed met object references die er niet waren.

Tuurlijk lijken die bitfields overbodig. Het gaat echter over het aangeven van hints aan de recordset user welke fields valid zijn en welke niet. Mandatory field code zal die velden links laten liggen, maar indien nodig is het t.a.t. verstandiger NULL values te mijden.

[Annie]

Op donderdag 21 februari 2002 16:16 schreef Otis o.a.:
Maar iedereen moet maar doen wat hij/zij het beste vindt. Mijn databases hebben nooit NULL values en veel prof. database designers denken er net zo over.

Ik vind dat je wel heel erg overtuigd bent van je gelijk
Er zijn waarschijnlijk net zoveel prof.db-ers die er anders over denken.
En opmerkingen als "nitwits" komen bij mij behoorlijk flame-erig over

btw.
ooit gehoord van coalesce(), isnull()

Op donderdag 21 februari 2002 16:16 schreef Otis het volgende:
Je komt er wel op terug, echt

jij ook

[Verwijderd]

Op donderdag 21 februari 2002 16:19 schreef r-e-m het volgende:

[en veel prof. database designers denken er net zo over]

Waar haal je dit vandaan..

C.J. Date "An Introduction to Database Systems, Volume II", pag 210-212.

Meneer Date lijkt me genoeg gewicht geven aan de stelling

[raptorix]

Uhm Northwind DB, de voorbeeld DB van MS bevat anders ook behoorlijk wat velden die Null zijn

Neem aan dat die niet door de eerste de beste prutser in elkaar zijn gezet

[Verwijderd]

Op donderdag 21 februari 2002 18:02 schreef raptorix het volgende:
Uhm Northwind DB, de voorbeeld DB van MS bevat anders ook behoorlijk wat velden die Null zijn

Neem aan dat die niet door de eerste de beste prutser in elkaar zijn gezet

haha til er niet te zwaar aan, joh Visual Studio Enterprise Architect komt met een leuke ORM modelling tool. Als je daar een datamodel mee maakt en je genereert daar je E/R model mee, dan krijg je ook NULL values in je tables, ivm de 0:n relaties ('hoeft niet, kan wel' ). Zoals ik al eerder zei: sommigen vinden het nuttig, anderen niet en vinden het juist verkeerd. Ok, ik was wat flamerig met 'nitwitts'. Idem met discussies over null-pointer tests, wat wel/niet OO is etc: er is altijd een groep die zegt: "het is/moet/ zo" en een andere groep die zegt: "nee het is/moet zo". C.J. Date geeft een aantal bezwaren aan in zn boek. Vind je die bezwaren niks, of vind je C.J. Date een eikel, wat mag, dan houdt niemand je tegen NULL values te gebruiken, tenslotte is veel database logica bij machte met NULL values om te gaan, staat elke database NULL values toe etc. Maar als ik de keuze had tussen NULL values en default values + eventueel semantische interpretatie ondersteunende fields dan koos ik voor het laatste. Ook default values zitten niet voor niks in een database als SQLserver: het geeft aan dat er een groep is die vindt dat het nuttig is en een andere groep die vindt het maar niks Dat zal altijd wel zo blijven denk ik.

[Verwijderd]

Op donderdag 21 februari 2002 16:16 schreef r-e-m het volgende:

[..]
Helemaal mee eens. 'NULL' geeft aan dat er geen data is. Net zoals wit (of zwart) geen kleur is. Daarom is het ideaal om aan te geven dat er nog geen data voor het desbetreffende veld aanwezig is. (en niet door het te vullen met een default waarde)

Nee, NULL geeft aan dat dat veld niet is geinitialiseerd. Daarop testen is exact hetzelfde als in VB een boolean definieren en er vanuit gaan dat hij 'false' is, want standaard wordt deze op 'false' gezet door de compiler. Een database hoeft in theorie geen 'NULL' in een veld te zetten, het veld is nl. niet geinitialiseerd. Theoretisch geneuzel, helemaal mee eens, maar in softwaredevelopment is het noodzaak de reden te weten waarom je doet en waarom iets is zoals het is.

[Annie]

Op donderdag 21 februari 2002 18:29 schreef Otis het volgende:
... Ok, ik was wat flamerig met 'nitwitts'...

*grouphug*

_{of mag dat alleen in /13 ?}

[Verwijderd]

Op vrijdag 22 februari 2002 11:34 schreef Annie het volgende:

[..]

*grouphug*

_{of mag dat alleen in /13 ?}

nee hoor, dat kan hier ook wel

[muis|IA]

uhm dit gaat me allemaal wat ver
Weet iemand misschien al een oplossing

[Verwijderd]

Op vrijdag 22 februari 2002 12:10 schreef muis het volgende:
uhm dit gaat me allemaal wat ver
Weet iemand misschien al een oplossing

Je vraag is toch al beantwoord? Die 1-1-1900 is de representatie van '0' als value van een datetime field.

[Verwijderd]

Leuk hoor, mensen die het wiel opnieuw willen uitvinden! Een discussie over Null-values lijkt me heel zinloos. Die dingen zijn ontwikkeld om de hierboven beschreven problemen op te lossen zonder extra velden aan je tabellen te hoeven toevoegen!

In het geval van VB/ASP/SQL is het een kwestie van een keer goed doorlezen hoe Null-values werken. Als je dat snapt (is niet zo heel moeilijk ) dan wil je niet meer zonder. Dat zou teruggaan naar het stenen computer-tijdperk betekenen...

[mulder]

Zou heel goed zonder kunnen, maar een default van 0 of 1-1-1900 vind ik gewoon niet relaxed. Dan heb ik liever NULL/NOT SET