[VB2010] Query werkt niet zoals gehoopt

[Alwinonline]

Ik ben een applicatie in Vb2010 aan het maken die gekoppeld is aan een access database. In deze database heb ik een Table genaamd Pakbonnen. Nu wil ik data uit een invoer veld van mijn Form vergelijken met data uit de database. Ik ben pas sinds kort bezig met VB dus ik heb al mijn ervaring uit tutorials gevonden online.

Mijn Table ziet er als volgt uit:
Table Pakbonnen
ID as AutoNumber
Locatie as text
Datum as Date/Time
PakbonNummer as Number

Nu wil ik met de volgende query de data ophalen:

code:

sql = "SELECT PakbonNummer FROM pakbonnen WHERE Datum = " & datum

deze data stop ik vervolgens in een dataset:

code:

da.Fill(ds, "pakbonnr")

Alleen komt hier nooit data in te staan (de ds bevat geen rijen en kolommen). Ik heb dit getest door middel van de volgende code

code:

msgbox(ds.tables("pakbonnr").Rows.Count())

Deze geeft 0 weer (wat volgens mij betekent dat er geen data in de dataset is opgeslagen)

Er staat wel data in de database dus hij zou iets op moeten halen. als ik de query weergeef in een messagebox staat deze er als volgt: SELECT PakbonNummer FROM pakbonnen WHERE Datum = 12/2/2011
dit zou goed moeten zijn want de datum word ook in die notatie opgeslagen in de db.

Ik ben nog maar een beginner dus ik loop tegen het probleem aan dat ik niet zo goed weet hoe ik dit zou moeten debuggen. Ik weet dat er een algemeen topic zou moeten zijn over hoe te debuggen maar dat kan ik nergens vinden?

Ik heb zo min mogelijk code geplakt om het relevant te houden maar mochten jullie meer informatie nodig hebben dan hoor ik het graag

[ Voor 4% gewijzigd door Alwinonline op 02-12-2011 10:17 ]

[Acid_Burn]

Je query is gewoon niet goed. Je kan een datum niet op die manier selecteren. Hij zal waarschijnlijk gewoon een som berekenen 12/2/2011. Daar moeten op zijn minst quotes omheen. En maar hopen dat het in de juiste format staat.

[Alwinonline]

Maar hoe pak ik dat dan aan. ik doe het nu namelijk op de volgende manier:
Ik werk met een dat/timepicker in mijn form. alleen wil ik alleen de datum gebruiken (dd/MM/YYYY)

voor het vullen van de datum variabele in de query gebruik ik dit:

code:

dim datum as Date
datum = <formname>.<datetimepickername>.Value.ToShortDateString()

ik gebruik <formname>.<datetimepickername>.Value.ToShortDateString() ook om de data uit de datetime picker in de database te zetten dus hij gebruikt hetzelfde format. Ik heb heel lang gegoogled maar kon uiteindelijk alleen deze manier gebruiken om een shortdate op te slaan in een database

[Acid_Burn]

Formateer je datum als volgt: YYYYMMDD en voer die als string aan je query. Deze notatie snapt de SQL server gewoon.

edit: als jij die datum op dezelfde manier invoert via een insert query dan denk ik dat die datum in de db ook gewoon niet goed is. Kijk daar ook maar eens naar.

[ Voor 41% gewijzigd door Acid_Burn op 02-12-2011 10:50 ]

[RobIII]

Lees dit eens (en dan ga je dit ook nodig hebben)
Better yet; gebruik Parametrized Queries

[ Voor 88% gewijzigd door RobIII op 02-12-2011 10:52 ]

[Alwinonline]

Acid_Burn schreef op vrijdag 02 december 2011 @ 10:46:
Formateer je datum als volgt: YYYYMMDD en voer die als string aan je query. Deze notatie snapt de SQL server gewoon.

edit: als jij die datum op dezelfde manier invoert via een insert query dan denk ik dat die datum in de db ook gewoon niet goed is. Kijk daar ook maar eens naar.

Het is gelukt.

Ik heb de datum van de input en de query op dezelfde manier geformat en nu pakt hij het wel. Het stomme is dat ik er vanuit was gegaan dat door "Value.ToShortDateString()"te gebruiken ik dezelfde format zou krijgen.

*Edit*

even voor de volledigheid (en eventueel anderen die hier iets aan hebben).
Ik maakte 2 fouten:
1, blijkbaar sloeg hij (ondanks het gebruik van Value.ToShortDateString()) de data niet in het juiste formaat op. dit heb ik opgelost door het volgende te gebruiken voor zowel de input in de database als de query: datum = Format(datetimepicker.value , "MM/dd/yyyy")
2.Om je query goed uit te voeren moet je om je om je datum variabele '#" hebben staan. mijn query ziet er nu als volgt uit:

code:

sql = "SELECT PakbonNummer FROM pakbonnen WHERE Datum = #" & datum ="#"

bedankt voor de hulp allemaal

[ Voor 33% gewijzigd door Alwinonline op 02-12-2011 12:23 ]

[RobIII]

Ik zou als ik jou was toch RobIII in "[VB2010] Query werkt niet zoals gehoopt" nog eens goed nalezen en, als 't effe kan, heel dat geneuzel met strings laten varen (lees: parameterized queries). Als je dan toch op strings staat, hanteer dan yyyymmdd (of yyyy-mm-dd); je applicatie werkt nu by the grace of some deity en straks op een andere locale gaat 't finaal op z'n bek.

En check dat je 200% zeker weet dat 't veld in je DB ook daadwerkelijk een DateTime is en geen varchar oid.

(En ja, voor Access dien je inderdaad #datestring# te gebruiken, maar dat staat los van dit alles)

[ Voor 10% gewijzigd door RobIII op 02-12-2011 12:57 ]

[Alwinonline]

RobIII schreef op vrijdag 02 december 2011 @ 12:56:
Ik zou als ik jou was toch RobIII in "[VB2010] Query werkt niet zoals gehoopt" nog eens goed nalezen en, als 't effe kan, heel dat geneuzel met strings laten varen (lees: parameterized queries). Als je dan toch op strings staat, hanteer dan yyyymmdd (of yyyy-mm-dd); je applicatie werkt nu by the grace of some deity en straks op een andere locale gaat 't finaal op z'n bek.

En check dat je 200% zeker weet dat 't veld in je DB ook daadwerkelijk een DateTime is en geen varchar oid.

(En ja, voor Access dien je inderdaad #datestring# te gebruiken, maar dat staat los van dit alles)

Ik zag je edit inderdaad nadat ik mijn post had gedaan pas en ben daar nu mee bezig. Ik heb het DB veld nagekeken en dit is inderdaad een date/time veld. Ik ben nu aan het stoeien met die parameterized queries

*edit* al snap ik deze opmerking:
je applicatie werkt nu by the grace of some deity en straks op een andere locale gaat 't finaal op z'n bek.

niet helemaal. wat ik ervan begrijp zijn paramaterized queries handig voor het versnellen van de queries omdat ze gecached worden. op de daadwerkelijke werking heeft het toch niet zoveel invloed? en wat bedoel je precies met een andere locale? als ik mijn input hetzelfde hou moet dit toch niet fout gaan?

btw ik werk niet met een string maar met een 'Date'

[ Voor 20% gewijzigd door Alwinonline op 02-12-2011 13:20 ]

[pedorus]

RobIII schreef op vrijdag 02 december 2011 @ 12:56:
je applicatie werkt nu by the grace of some deity en straks op een andere locale gaat 't finaal op z'n bek.

Nu wil het geval dat dit bij Access toevallig wel altijd goed gaat (al kijk je over die "=" ipv "&" heen).

quote: http://allenbrowne.com/ser-36.html

Access expects these literal dates to be in the American format, e.g. #12/31/1999#

Dat neemt niet weg dat dit een vrij beroerde stijl van programmeren is, en parameterized queries of Linq of ? beter werkt (helaas is een access database niet te prefereren en is linq daardoor maar deels ondersteund).

[RobIII]

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
*edit* al snap ik deze opmerking:
je applicatie werkt nu by the grace of some deity en straks op een andere locale gaat 't finaal op z'n bek.

niet helemaal

Ik ben niet 100% bekend met Access in deze (en als wat pedorus zegt waar is is 't probleem hooguit minder, maar leer je 't alsnog 'verkeerd' aan), maar wat een locale is kun je prima zelf uitzoeken/lezen. Je werkt nu op je eigen systeem met instelling X (of dat nou DD-MM-YYYY of MM/DD/YYYY is of whatever) en als je straks je applicatie uitrolt en wordt geïnstalleerd bij een gebruiker met instelling Y die niet overeenkomt met de jouwe dan heb je een probleem.

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
wat ik ervan begrijp zijn paramaterized queries handig voor het versnellen van de queries omdat ze gecached worden.

Ja, nee, soms. Met parameterized queries, en daar gaat het hier even om, heb je 't voordeel dat de driver alle "formattering" (die er niet eens is; de datum gaat gewoon als datum naar de DB i.p.v. als een string) afhandelt. Daarmee ben je, bijv., ook automatisch veilig voor SQL injections.

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
op de daadwerkelijke werking heeft het toch niet zoveel invloed?

Juist wel.

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
en wat bedoel je precies met een andere locale?

As said; je werkt nu op (zeg) een nl-NL systeem, gebruiker Q werkt misschien wel met en-US instellingen. Welke datum bedoel ik nou met 02/12/1977? You tell me: 2 december 1977 of 12 februari 1977?

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
als ik mijn input hetzelfde hou moet dit toch niet fout gaan?

Assumptions are the mother of all f*ckups

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
btw ik werk niet met een string maar met een 'Date'

Nee; je werkt met een string! Op 't moment waar je zegt:

Visual Basic .NET:

foo = bar.Value.ToString();

...ben je 't DateTime type dat .Value teruggaf kwijt; je hebt 't namelijk expliciet naar een string geconverteerd. Daarna ga je met wat string-plakken de variabele foo (welke dus al een string is!!) in een stukje SQL-string plakken. Alle datetime-info (zo ook bijv. tijdzone / wel/niet-UTC etc.-info) kwijt.

[ Voor 3% gewijzigd door RobIII op 02-12-2011 13:44 ]

[keesdewit]

strings aan elkaar knutselen en daar een sql commando mee maken is echt bad practice. Probeer eens iets als Linq uit.

[whoami]

Alwinonline schreef op vrijdag 02 december 2011 @ 13:16:
[...]


Ik zag je edit inderdaad nadat ik mijn post had gedaan pas en ben daar nu mee bezig. Ik heb het DB veld nagekeken en dit is inderdaad een date/time veld. Ik ben nu aan het stoeien met die parameterized queries

*edit* al snap ik deze opmerking:
je applicatie werkt nu by the grace of some deity en straks op een andere locale gaat 't finaal op z'n bek.

niet helemaal. wat ik ervan begrijp zijn paramaterized queries handig voor het versnellen van de queries omdat ze gecached worden. op de daadwerkelijke werking heeft het toch niet zoveel invloed? en wat bedoel je precies met een andere locale? als ik mijn input hetzelfde hou moet dit toch niet fout gaan?

btw ik werk niet met een string maar met een 'Date'

Het grote voordeel van parametrized queries, is, dat je zelf geen zorgen hoeft te maken over het formaat waarin je de datum aan je DB doorgeeft.
Als je uw query gaat opbouwen dmv string-concat, moet je er wel voor zorgen dat je uw datum zo doorgeeft, dat uw DB 'm snapt. (Door 'm bv in het 'YYYYMMDD' formaat door te geven in SQL Server, als je Access gebruikt, is dat dan weer een andere string (met # errond, en ik weet nu niet meer of je wel of niet scheidingstekens moet gebruiken tussen de verschillende delen, en in welke volgorde die moeten komen).

Het andere grote voordeel is, dat je je ook geen zorgen hoeft te maken over sql-injection.

[RobIII]

keesdewit schreef op vrijdag 02 december 2011 @ 13:43:
strings aan elkaar knutselen en daar een sql commando mee maken is echt bad practice. Probeer eens iets als Linq uit.

Linq(2SQL) werkt niet met Access AFAIK, Waar je naar wil kijken is EF of gewoon ADO.Net. Who cares.

[edit]
Ah, deze schijnt 't te kunnen; van MS-eigen implementaties vind ik her-en-der ook beweringen maar die kan ik niet verifiëren.

[ Voor 24% gewijzigd door RobIII op 02-12-2011 13:53 ]

[Alwinonline]

RobIII schreef op vrijdag 02 december 2011 @ 13:43:
[...]

Ik ben niet 100% bekend met Access in deze (en als wat pedorus zegt waar is is 't probleem hooguit minder, maar leer je 't alsnog 'verkeerd' aan), maar wat een locale is kun je prima zelf uitzoeken/lezen. Je werkt nu op je eigen systeem met instelling X (of dat nou DD-MM-YYYY of MM/DD/YYYY is of whatever) en als je straks je applicatie uitrolt en wordt geïnstalleerd bij een gebruiker met instelling Y die niet overeenkomt met de jouwe dan heb je een probleem.


[...]

Ja, nee, soms. Met parameterized queries, en daar gaat het hier even om, heb je 't voordeel dat de driver alle "formattering" (die er niet eens is; de datum gaat gewoon als datum naar de DB i.p.v. als een string) afhandelt. Daarmee ben je, bijv., ook automatisch veilig voor SQL injections.


[...]

Juist wel.


[...]

As said; je werkt nu op (zeg) een nl-NL systeem, gebruiker Q werkt misschien wel met en-US instellingen. Welke datum bedoel ik nou met 02/12/1977? You tell me: 2 december 1977 of 12 februari 1977?


[...]

Assumptions are the mother of all f*ckups


[...]

Nee; je werkt met een string! Op 't moment waar je zegt:

Visual Basic .NET:

foo = bar.Value.ToString();

...ben je 't DateTime type dat .Value teruggaf kwijt; je hebt 't namelijk expliciet naar een string geconverteerd. Daarna ga je met wat string-plakken de variabele foo (welke dus al een string is!!) in een stukje SQL-string plakken. Alle datetime-info (zo ook bijv. tijdzone / wel/niet-UTC etc.-info) kwijt.

laat ik voorop stellen dat ik me ervan bewust ben dat het fout is en dat ik vanaf nu ook parameterized queries ga gebruiken, alleen schrok ik een beetje van de opmerking dat de hele applicatie over zijn nek gaat als ik het niet aan zou passen.

een klein misverstand is dat jij er vanuit gaat dat ik nog foo.bar.value.tostring() gebruik, dat is niet zo. Ik gebruik de volgende code:

Visual Basic .NET:

dim datum as date
datum = Format(datetimepicker.value, 'MM/dd/yyyy")

daardoor voorkom ik toch dat andere systemen invloed hebben op de data die ik in de database stop? omdat ik (wat de input ook is) ik deze format naar het juiste type?

Ik vraag dit omdat als ik parameterized queries gebruik ik de data nog steeds in de parameters moet stoppen, en als ik deze manier daarvoor zou gebruiken dit dan ook fout zou zijn.

[whoami]

Er staat wel data in de database dus hij zou iets op moeten halen. als ik de query weergeef in een messagebox staat deze er als volgt: SELECT PakbonNummer FROM pakbonnen WHERE Datum = 12/2/2011
dit zou goed moeten zijn want de datum word ook in die notatie opgeslagen in de db.

Je datum wordt niet in die notatie in de DB opgeslagen. Uw datum wordt als een getal opgeslagen.
Dat jij denk dat die datum als 12/2/2011 wordt opgeslagen, komt gewoon omdat de UI van Access die datum zo weergeeft.

laat ik voorop stellen dat ik me ervan bewust ben dat het fout is en dat ik vanaf nu ook parameterized queries ga gebruiken, alleen schrok ik een beetje van de opmerking dat de hele applicatie over zijn nek gaat als ik het niet aan zou passen.

Daar heeft RobIII wel gelijk in hoor.

een klein misverstand is dat jij er vanuit gaat dat ik nog foo.bar.value.tostring() gebruik, dat is niet zo. Ik gebruik de volgende code:

Visual Basic .NET:

dim datum as date
datum = Format(datetimepicker.value, 'MM/dd/yyyy")

daardoor voorkom ik toch dat andere systemen invloed hebben op de data die ik in de database stop? omdat ik (wat de input ook is) ik deze format naar het juiste type?

Zoals ik al zei, de datum wordt als een getal in de DB opgeslagen.

Men zou moeten verplicht worden om geen VB.NET te gebruiken als men leert programmeren; want die laat toe om niet strong typed te gaan programmeren, en dan komt men met zo'n lelijke constructies als deze

De Format method nog altijd een string, en geen datum.
Dat je blijkbaar het resultaat van die method (die string), dus aan een datum kunt gaan toewijzen, kan volgens mij alleen maar omdat er dan een impliciete cast gebeurd.

Ik vraag dit omdat als ik parameterized queries gebruik ik de data nog steeds in de parameters moet stoppen, en als ik deze manier daarvoor zou gebruiken dit dan ook fout zou zijn.

Als je parametrized queries gebruikt, dan stop je gewoon de waarde van die datum in de 'Value' property van die parameter.

zo dus:

code:

DateTime theDate = new DateTime (2011, 7, 15);
myCommand.Parameters["someDateParameter"].Value = theDate;

[ Voor 72% gewijzigd door whoami op 02-12-2011 14:00 ]

[RobIII]

Alwinonline schreef op vrijdag 02 december 2011 @ 13:51:
een klein misverstand is dat jij er vanuit gaat dat ik nog foo.bar.value.tostring() gebruik, dat is niet zo. Ik gebruik de volgende code:

Visual Basic .NET:

dim datum as date
datum = Format(datetimepicker.value, 'MM/dd/yyyy")

Daarmee cast je een Date naar een string (dat doet de Format) die je vervolgens impliciet weer naar een Date cast (want: "datum" is type Date, de = operator zal impliciet de string die uit Format komt casten naar Date) En die mik je vervolgens in de SQL string en daar ben je weer overgeleverd aan de ToString implementatie (die voor je wordt aangeroepen omdat je een string + date aan elkaar probeert te plakken met de & operator) die gewoon zal doen wat 'ie moet doen: de locale-formatted string teruggeven. Met andere woorden: in 3 regels code 15 fuckups

Alwinonline schreef op vrijdag 02 december 2011 @ 13:51:
daardoor voorkom ik toch dat andere systemen invloed hebben op de data die ik in de database stop? omdat ik (wat de input ook is) ik deze format naar het juiste type?

Nee; lees je eens in in (expliciete danwel impliciete) casting. En had VB.net daar niet zo'n statement voor...*denkt*... Option Strict? Gebruik je dat wel?

Alwinonline schreef op vrijdag 02 december 2011 @ 13:51:
Ik vraag dit omdat als ik parameterized queries gebruik ik de data nog steeds in de parameters moet stoppen, en als ik deze manier daarvoor zou gebruiken dit dan ook fout zou zijn.

Neen, dan begrijp je parameterized queries niet.

Je hebt 't overigens steeds over "date", maar heel dat type bestaat volgens mij niet Bedoel je niet DateTime?
Ah. [url="http://msdn.microsoft.com/en-us/library/3eaydw6e(v=VS.100).aspx[/url]

Framework Type. The corresponding type in the .NET Framework is the System.DateTime structure.

[ Voor 53% gewijzigd door RobIII op 02-12-2011 14:06 ]

[Alwinonline]

zucht ik heb nog veel te leren blijkbaar. ik ga hier vanavond mijn hoofd maar weer over breken, het begint nu allemaal een beetje te draaien namelijk

[glmona]

Wat ie dus bedoelt is, dat je onderstaande beter kan gebruiken, omdat er dan geen casting is:

Visual Basic .NET:

dim datum as date
datum = datetimepicker.value

En dan de datum gebruiken in een parameterized query

[ Voor 15% gewijzigd door glmona op 02-12-2011 14:06 ]

[RobIII]

glmona schreef op vrijdag 02 december 2011 @ 14:05:
Wat ie dus bedoelt is, dat je onderstaande beter kan gebruiken, omdat er dan geen casting is:

Wat is heel 't nut überhaupt nog van die datum variabele? Kun je net zo goed meteen die datetimepicker-value in de SQL string gooien:

Visual Basic .NET:

sql = "SELECT PakbonNummer FROM pakbonnen WHERE Datum = " & datetimepicker.value

Heel 't eiereneten is nou net dat je dat niet wil.

glmona schreef op vrijdag 02 december 2011 @ 14:05:
En dan de datum gebruiken in een parameterized query

^ Dat stond er net niet; stiekem editten (Kan er zelf ook wat van hoor ).
Anyway; ook in dat geval is heel de "datum" variabele natuurlijk gewoon overbodig...

Visual Basic .NET:

dim datum as date 
datum = datetimepicker.value
myCmd.Parameters.Add("@foo", SqlDbType.DateTime, datum)

Vs:

Visual Basic .NET:

myCmd.Parameters.Add("@foo", SqlDbType.DateTime, datetimepicker.value)

[ Voor 36% gewijzigd door RobIII op 02-12-2011 14:11 ]

[BvDorp]

Interessant topic, zie veel van wat ik zelf ook heb moeten leren toen ik ging werken met VB.Net. Het is belangrijk om je te verdiepen in object-oriented programmeren, en jezelf aan te leren eerst op zoek te gaan naar een 'best practice' voordat je zomaar lukraak wat in elkaar gaat knallen. Tegelijkertijd is het wel mooi om gewoon goed te stoeien en te rotzooien, maar hou voor jezelf goed in de gaten wat je code-kwaliteit is. Mij heeft het ontzettend veel geholpen af en toe wat vrienden te laten kijken naar stukken code; die konden dan aangeven waar ik misging qua logica, performance of overzichtelijkheid.

Ook is het mooi jezelf te verdiepen in wat programmeer-methodes; zelf heb ik altijd hartelijk moeten lachen om Extreme Programming.

Belangrijkste blijft natuurlijk: lekker doorprogrammeren! Je loopt vanzelf in de valkuilen en leert vanzelf alle begrippen die hier genoemd staat begrijpen.

[Alwinonline]

RobIII schreef op vrijdag 02 december 2011 @ 14:07:
[...]


Wat is heel 't nut überhaupt nog van die datum variabele? Kun je net zo goed meteen die datetimepicker-value in de SQL string gooien:

Visual Basic .NET:

sql = "SELECT PakbonNummer FROM pakbonnen WHERE Datum = " & datetimepicker.value

Heel 't eiereneten is nou net dat je dat niet wil.


[...]

^ Dat stond er net niet; stiekem editten (Kan er zelf ook wat van hoor ).
Anyway; ook in dat geval is heel de "datum" variabele natuurlijk gewoon overbodig...

Visual Basic .NET:

dim datum as date 
datum = datetimepicker.value
myCmd.Parameters.Add("@foo", SqlDbType.DateTime, datum)

Vs:

Visual Basic .NET:

myCmd.Parameters.Add("@foo", SqlDbType.DateTime, datetimepicker.value)

De reden dat ik de value niet direct in de db wil stoppen is omdat de datetimepicker standaard dd/MM/yyyy ss/mm/hh gebruikt en ik alleen de datum (en dus niet de tijd) wil toevoegen aan de database. Dat is de reden dat ik hem eerst naar een andere format moet converteren voordat ik hem in de database stop. Dit kan natuurlijk direct in de sql maar ik vind het in een variabele 9datum0 makkelijk voor mijzelf om het overzichtelijk te houden.

BvDorp schreef op vrijdag 02 december 2011 @ 14:09:
Interessant topic, zie veel van wat ik zelf ook heb moeten leren toen ik ging werken met VB.Net. Het is belangrijk om je te verdiepen in object-oriented programmeren, en jezelf aan te leren eerst op zoek te gaan naar een 'best practice' voordat je zomaar lukraak wat in elkaar gaat knallen. Tegelijkertijd is het wel mooi om gewoon goed te stoeien en te rotzooien, maar hou voor jezelf goed in de gaten wat je code-kwaliteit is. Mij heeft het ontzettend veel geholpen af en toe wat vrienden te laten kijken naar stukken code; die konden dan aangeven waar ik misging qua logica, performance of overzichtelijkheid.

Ook is het mooi jezelf te verdiepen in wat programmeer-methodes; zelf heb ik altijd hartelijk moeten lachen om Extreme Programming.

Belangrijkste blijft natuurlijk: lekker doorprogrammeren! Je loopt vanzelf in de valkuilen en leert vanzelf alle begrippen die hier genoemd staat begrijpen.

Ik probeer zoveel mogelijk best-practises te zoeken maar helaas vind ik dit vrij lastig te vinden. ik doe mijn best maar het lukt niet altijd. en over die tip van vrienden nakijken: dat zou ik heel graag willen maar ik ken verder niemand die bekend is met vb.net dus het blijft voor mij stoeien en leren van topics zoals deze

[ Voor 35% gewijzigd door Alwinonline op 02-12-2011 14:18 ]

[whoami]

Alwinonline schreef op vrijdag 02 december 2011 @ 14:16:
[...]


De reden dat ik de value niet direct in de db wil stoppen is omdat de datetimepicker standaard dd/MM/yyyy ss/mm/hh gebruikt en ik alleen de datum (en dus niet de tijd) wil toevoegen aan de database. Dat is de reden dat ik hem eerst naar een andere format moet converteren voordat ik hem in de database stop. Dit kan natuurlijk direct in de sql maar ik vind het in een variabele 9datum0 makkelijk voor mijzelf om het overzichtelijk te houden.

Oplossing:

code:

datetimePicker.Value.Date

Value is nl. een DateTime, en een DateTime struct heeft een Date property, die een DateTime returned waarbij de tijd op 0 staat.

[RobIII]

Alwinonline schreef op vrijdag 02 december 2011 @ 14:16:
De reden dat ik de value niet direct in de db wil stoppen is omdat de datetimepicker standaard dd/MM/yyyy ss/mm/hh gebruikt

Wat whoami zegt; maar los daarvan: ik neem aan dat je hh:mm:ss bedoelt i.p.v. ss/mm/hh

[Alwinonline]

Ja dat bedoelde ik, en dat van whoami wist ik idd niet, al klinkt het nu logisch. Ik moet toch beter lezen op technet want hier stond het inderdaad ook.