Black Friday = Pricewatch Bekijk onze selectie van de beste Black Friday-deals en voorkom een miskoop.

[c#] access datetime doet raar

Pagina: 1
Acties:

  • elgringo
  • Registratie: Januari 2001
  • Laatst online: 16-09 20:30
Ik heb een datatable in een access database waar een datetime de primaire sleutel is.

Hier voeg ik met de statement "INSERT INTO tabel VALUES(#yyyy-mm-dd hh:mm:ss#..."
waarden is. Dus #2008-29-09 11:15:00#. Dit komt ook in de access db te staan.

Als ik hem wil ophalen (of verwijderen oid) met SELECT * FROM tabel WHERE datum=#2008-29-09 11:15:00#.
Dan krijg ik de record die ik net ingevoerd heb met deze datum /tijd niet terug.

Als ik Datum>#2008-29-09 11:14:59# AND Datum<#2008-29-09 11:15:01# gebruik pakt ie hem wel.

Erger is nog het volgende: ik heb zelf een datetime toegevoegd bijv. 2008-29-09 11:14:59, die in de access db (als ik hem met access open) als 2008-29-09 11:50:00 staat. Dus een seconde ernaast.

Ik heb het idee dat dit door milliseconden komt, maar ik weet niet hoe ik dit op moet lossen, wie kan me verder helpen?

if broken it is, fix it you should


  • lier
  • Registratie: Januari 2004
  • Laatst online: 17:01

lier

MikroTik nerd

Oké...eerste tip: gebruik geen datum als primary key.

Hoe belangrijk zijn de milliseconden ?
Vergelijken waarbij je de milliseconden altijd op 00 gezet worden een optie ?
Zorgen dat in de database seconden als meest nauwkeurig opgeslagen worden (en geen milliseconden) ?

Wat is nu eigenlijk exact je vraag ?

Eerst het probleem, dan de oplossing


  • elgringo
  • Registratie: Januari 2001
  • Laatst online: 16-09 20:30
lier schreef op maandag 29 september 2008 @ 11:23:
Oké...eerste tip: gebruik geen datum als primary key.
Waarom niet, (zeg ik dat de nauwkeurigheid een seconde is)?
Hoe belangrijk zijn de milliseconden ?
Niet, ik wil ze weg hebben...
Vergelijken waarbij je de milliseconden altijd op 00 gezet worden een optie ?
bij toevoegen geef ik geen milliseconden mee, waar komen deze vandaan?
Als ik toevoeg als #yyyy-mm-dd hh:mm:ss.000# werkt het ook niet. Dan krijg ik een oledb error.
Hoe kan ik deze op 0 zetten en zo invoegen?
Zorgen dat in de database seconden als meest nauwkeurig opgeslagen worden (en geen milliseconden) ?
Hoe krijg ik dat voor elkaar
Wat is nu eigenlijk exact je vraag ?
Simpel hoe kan ik datatime toevoegen en ophalen, met een nauwkeurigheid van een seconde zodat ik een datum die ik net heb toegevoegd ook eruit kan halen.

if broken it is, fix it you should


  • lier
  • Registratie: Januari 2004
  • Laatst online: 17:01

lier

MikroTik nerd

elgringo schreef op maandag 29 september 2008 @ 11:28:
[...]
Waarom niet, (zeg ik dat de nauwkeurigheid een seconde is)?
Je pkey is een technische sleutel, je gaat hier geen data in op slaan.
[...]
Niet, ik wil ze weg hebben...
Waarom staan ze er dan in ?
[...]
bij toevoegen geef ik geen milliseconden mee, waar komen deze vandaan?
Als ik toevoeg als #yyyy-mm-dd hh:mm:ss.000# werkt het ook niet. Dan krijg ik een oledb error.
Hoe kan ik deze op 0 zetten en zo invoegen?
Jij stopt de data erin...dan moet je ook weten wat je weg schrijft...!?
[...]
Hoe krijg ik dat voor elkaar
Jij stopt de data erin...dan moet je ook weten wat je weg schrijft...!?
[...]
Simpel hoe kan ik datatime toevoegen en ophalen, met een nauwkeurigheid van een seconde zodat ik een datum die ik net heb toegevoegd ook eruit kan halen.
Converteer je datum naar een datum dat volgens jouw formaat is...simple :P

Eerst het probleem, dan de oplossing


  • elgringo
  • Registratie: Januari 2001
  • Laatst online: 16-09 20:30
lier schreef op maandag 29 september 2008 @ 11:34:
[...]

Je pkey is een technische sleutel, je gaat hier geen data in op slaan.
Dat is een beetje krom. De meeste tabellen hebben een pkey die wel data is (ie afdelingsnummer, sofinummer etc.) Ik vond het niet nodig om een extra kolom erin te gaan zetten met een bijv een int als pkey. En ik dacht dat een datetime gewoon yyyy-mm-dd hh:mm:ss en niet nauwkeuriger.
Waarom staan ze er dan in ?
Dat weet ik niet.... Ik wil ze er niet in hebben en in access kan je niet al te veel wijzigen. Alle tijden die hij laat zien is op de seconde afgerond. Als het mogelijk is deze niet op te slaan zou ik dat graag willen weten en dan is het probleem opgelost.
Jij stopt de data erin...dan moet je ook weten wat je weg schrijft...!?
Ja dat weet ik ook. Stel die tabel bavat een kolom met datetime en heet tbl.
Dan voeg ik dit toe: INSERT INTO tbl VALUES(#2008-29-09 11:15:00#)
Als ik hem verwijder met :DELETE FROM tbl WHERE datum=#2008-29-09 11:15:00#
verwijdert die hem niet, dus access heeft er data (milliseconden vermoed ik) bijverzonnen. Ik het ergste geval zat er dus een seconde naast, zoals ik vertelde.
Converteer je datum naar een datum dat volgens jouw formaat is...simple :P
Dat wil ik heel graag, maar ik weet niet hoe je dat in access doet. Access kent maar 1 datetime

if broken it is, fix it you should


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 15-11 11:40

Janoz

Moderator Devschuur®

!litemod

elgringo schreef op maandag 29 september 2008 @ 11:45:
[...]

Dat is een beetje krom. De meeste tabellen hebben een pkey die wel data is (ie afdelingsnummer, sofinummer etc.) Ik vond het niet nodig om een extra kolom erin te gaan zetten met een bijv een int als pkey. En ik dacht dat een datetime gewoon yyyy-mm-dd hh:mm:ss en niet nauwkeuriger.
Dan zijn dus eigenlijk de meeste tabellen fout. Jij hebt nu een probleem wanneer afdelingen samengevoegd gaan worden of wanneer het sofinummer uitgefaseerd wordt (we hebben immers tegenwoordig het BSN)

Maar om op je probleem terug te komen. Er zijn twee mogelijkheden:
1. In je C# code zet je de tijd van je tijd object, maar vergeet je de miliseconden aan te passen (waardoor deze blijven staan op de waarde van de aanmaaktijd)
2. In Access wordt, omdat er niks gespecificeerd is, de miliseconden van de huidige tijd genomen.

Probleem is op te lossen door zelf de miliseconden op 0 te zetten, en nee, dat doe je niet door je formatter aan te passen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • elgringo
  • Registratie: Januari 2001
  • Laatst online: 16-09 20:30
Janoz schreef op maandag 29 september 2008 @ 11:53:
[...]

Dan zijn dus eigenlijk de meeste tabellen fout. Jij hebt nu een probleem wanneer afdelingen samengevoegd gaan worden of wanneer het sofinummer uitgefaseerd wordt (we hebben immers tegenwoordig het BSN)

Maar om op je probleem terug te komen. Er zijn twee mogelijkheden:
1. In je C# code zet je de tijd van je tijd object, maar vergeet je de miliseconden aan te passen (waardoor deze blijven staan op de waarde van de aanmaaktijd)
2. In Access wordt, omdat er niks gespecificeerd is, de miliseconden van de huidige tijd genomen.

Probleem is op te lossen door zelf de miliseconden op 0 te zetten, en nee, dat doe je niet door je formatter aan te passen.
Hoe kan ik dan de huidige milliseconden van de betsaande records op 0 zetten?
En hoe kan ik bij het toevoegeen van een tijd de milliseocnden als 0 doorgeven?

if broken it is, fix it you should


  • bigbeng
  • Registratie: Augustus 2000
  • Laatst online: 26-11-2021
Volgens deze site is een Date eigenlijk een Double, dus een floating point getal. Met floating point getallen vergelijkingen doen kan tot rare/onverwachte resultaten leiden. Desondanks zou ik gezien jouw codevoorbeelden toch verwachten dat dezelfde datum-input tot dezelfde basiswaarde zou leiden, waardoor jouw record toch zou worden opgepakt.

En wat betreft synthetische primaire sleutels, het is i.h.a aan te raden om geen primaire sleutel te maken op een tabel die voor iets anders dient dan een primaire sleutel. Dus data die over tijd wijzigt, en/of een betekenis toekent aan het record waar hij deel van uitmaakt is niet aan te raden. Bovendien kunnen foreign key relaties in het geding komen als de waarde van de primary key wijzigt.
Als dergelijke overwegingen niet van toepassing zijn, dan kun je het besluit nemen om wel een natuurlijke sleutel als primaire sleutel te gebruiken. :7

  • elgringo
  • Registratie: Januari 2001
  • Laatst online: 16-09 20:30
bigbeng schreef op maandag 29 september 2008 @ 12:11:
Volgens deze site is een Date eigenlijk een Double, dus een floating point getal. Met floating point getallen vergelijkingen doen kan tot rare/onverwachte resultaten leiden. Desondanks zou ik gezien jouw codevoorbeelden toch verwachten dat dezelfde datum-input tot dezelfde basiswaarde zou leiden, waardoor jouw record toch zou worden opgepakt.

En wat betreft synthetische primaire sleutels, het is i.h.a aan te raden om geen primaire sleutel te maken op een tabel die voor iets anders dient dan een primaire sleutel. Dus data die over tijd wijzigt, en/of een betekenis toekent aan het record waar hij deel van uitmaakt is niet aan te raden. Bovendien kunnen foreign key relaties in het geding komen als de waarde van de primary key wijzigt.
Als dergelijke overwegingen niet van toepassing zijn, dan kun je het besluit nemen om wel een natuurlijke sleutel als primaire sleutel te gebruiken. :7
Ik had inderdaad vernomen dat het een double was, maar heeft blijft natuurlijk wat wazig waarom de datetime die ik schrijf anders in dan die ik lees. En belangrijker nog, hoe los ik dit op?

if broken it is, fix it you should


  • bigbeng
  • Registratie: Augustus 2000
  • Laatst online: 26-11-2021
Je zou kunnen beginnen met onderzoeken waar het verschil hem in zit. Mijn eerste poging zou zijn om de datums naar een double om te zetten en die eens weer te geven. Of het verschil tussen de twee doubles. En die vervolgens met 24*60*60*1000 vermenigvuldigen en dan kun je zien hoever ze uit elkaar liggen (in milliseconden).
En dan met een bandbreedte gaan werken die jij acceptabel vindt.

Misschien ook wat handige informatie:
Access: Datum-/tijdgegevens opslaan, berekenen en vergelijken
Pagina: 1