[mysql] dichtsbijzijnde datum

[Verwijderd]

Ik probeer in op een phppagina het volgende evenement te tonen. Dit probeer ik met deze query:

code:

select * from evenement where startdatum >= $datum

datum is de datum van vandaag

Wanneer ik deze query uitvoer krijg ik alle evenementen te zien van het hele jaar in plaats van de evenementen die nog moeten plaatsvinden.

Wat doe ik verkeerd in mijn query? Is het Überhaupt wel mogelijk om op de volgende datum te zoeken.

bvd

[Creepy]

Wat is startdatum voor type in je database en wat zie je terug als je de volledige query op het scherm print (aka: wat heeft $datum voor waarde).

[douweh]

Je zoekt nu àlle entries waarbij de startdatum groter of gelijk aan de $datum variabele is.
Als je er maar 1 terug wil krijgen dan moet je een LIMIT toepassen, daarover kan je veel vinden in de mysql handleiding!

succes!

[Verwijderd]

Creepy schreef op maandag 30 maart 2009 @ 10:36:
Wat is startdatum voor type in je database en wat zie je terug als je de volledige query op het scherm print (aka: wat heeft $datum voor waarde).

Hij stond op varchar, waarschijnlijk omdat het zo in het sql bestand stond. Ik heb het nu op date gezet.
Alle data zijn nu weg, en nu wordt de datum 0000-00-00 weergegeven in plaats van 00-00-0000

enig idee hoe ik dit aanpas in PhpmyAdmin

Is het mogelijk om in mijn sql file het volgende te zetten:

code:

`startdatum` date(d-m-Y) default NULL

in plaats van

code:

`startdatum` date default NULL

[ Voor 15% gewijzigd door Verwijderd op 30-03-2009 10:58 ]

[dev10]

Verwijderd schreef op maandag 30 maart 2009 @ 10:49:
[...]

Hij stond op varchar, waarschijnlijk omdat het zo in het sql bestand stond. Ik heb het nu op date gezet.
Alle data zijn nu weg, en nu wordt de datum 0000-00-00 weergegeven in plaats van 00-00-0000

enig idee hoe ik dit aanpas in PhpmyAdmin

Is het mogelijk om in mijn sql file het volgende te zetten:

code:

`startdatum` date(d-m-Y) default NULL

in plaats van

code:

`startdatum` date default NULL

Natuurlijk heb je een back-up gemaakt. Nu is het moment om die terug te zetten.

[Verwijderd]

Lees dit artikel maar eens dan leer je hoe je goed met mysql dates kan werken.
succes

[MueR]

Je bedoelt dat de datum nu wordt opgeslagen zoals een datum dat hoort te doen? Je localisatie zal je echt in je presentatie moeten doen, niet in je database. (Dus: Nee, dat kan niet. Datums werken nu eenmaal zo)

[Verwijderd]

Natuurlijk heb je een back-up gemaakt. Nu is het moment om die terug te zetten.

Ja die heb ik, maar ik vroeg me af of het mogelijk is om in mijn back-up file (.sql) aan te geven dat hij van de tabel startdatum een datum tabel maakt met als volgorde d-m-Y.

Want nu staat het in de verkeerde volgorde waardoor de datums niet ingelezen worden.

[Verwijderd]

Verwijderd schreef op maandag 30 maart 2009 @ 11:07:
[...]


Ja die heb ik, maar ik vroeg me af of het mogelijk is om in mijn back-up file (.sql) aan te geven dat hij van de tabel startdatum een datum tabel maakt met als volgorde d-m-Y.

Want nu staat het in de verkeerde volgorde waardoor de datums niet ingelezen worden.

Tuurlijk kan dat. Het is gewoon een SQL-bestand...

[Verwijderd]

Eerder sloeg je de datum op als varchar, daarom werkte je >= niet, je vergelijkt varchars geen datums.
Omdat je de datum opgeslagen had in d-m-Y formaat snapt mysql de datum niet en maakt hij van alles 0000-00-00.

Hoe de datum in je database komt te staan kan je niet aanpassen. Dit is ook niet van belang want dat kan je in de presentatie laag wel aanpassen.

[Verwijderd]

Verwijderd schreef op maandag 30 maart 2009 @ 11:14:
Eerder sloeg je de datum op als varchar, daarom werkte je >= niet, je vergelijkt varchars geen datums.
Omdat je de datum opgeslagen had in d-m-Y formaat snapt mysql de datum niet en maakt hij van alles 0000-00-00.

Hoe de datum in je database komt te staan kan je niet aanpassen. Dit is ook niet van belang want dat kan je in de presentatie laag wel aanpassen.

Dus nu moet ik zelf de datums in mijn sql file aanpassen?

[Rian]

Misschien is het sowieso een idee om de datums in je database in vorm van een unix timestamp op te slaan. Persoonlijk vind ik dit veel prettiger. Bij het sorteren en zoeken op datums heb je dan ook geen problemen met de volgorde.

In php kun je datums naar een timestamp converteren mbv mktime( ), en van timestamp naar "gewone" datum door middel van date( 'd-m-Y', $timestamp ).

En je wilde ook je sql file aanpassen, je wilde de datum column aanpassen, als ik het goed begrijp? Die kun je zoals eerder aangegeven, heel simpel wijzigen. Als je met timestamps werkt, kun je er gewoon een int(1) van maken:
SET datum INT(1) NOT NULL;
Uit mijn hoofd dacht ik dat dit wel moet kloppen.

Succes!

[Verwijderd]

Verwijderd schreef op maandag 30 maart 2009 @ 11:15:
[...]


Dus nu moet ik zelf de datums in mijn sql file aanpassen?

Je zal je sql wel moeten updaten maar je hoeft niet alle datums handmatig te gaan updaten:
http://dev.mysql.com/doc/...html#function_str-to-date

[Verwijderd]

Bedankt allemaal ik heb het werkend.
Het probleem was dat mijn velden als VARCHAR ingesteld stonden

[Cartman!]

Rian schreef op maandag 30 maart 2009 @ 11:16:
Misschien is het sowieso een idee om de datums in je database in vorm van een unix timestamp op te slaan. Persoonlijk vind ik dit veel prettiger. Bij het sorteren en zoeken op datums heb je dan ook geen problemen met de volgorde.

In php kun je datums naar een timestamp converteren mbv mktime( ), en van timestamp naar "gewone" datum door middel van date( 'd-m-Y', $timestamp ).

En je wilde ook je sql file aanpassen, je wilde de datum column aanpassen, als ik het goed begrijp? Die kun je zoals eerder aangegeven, heel simpel wijzigen. Als je met timestamps werkt, kun je er gewoon een int(1) van maken:
SET datum INT(1) NOT NULL;
Uit mijn hoofd dacht ik dat dit wel moet kloppen.

Succes!

Naaah... Sla maar eens een datum op van 1 januari 1920, bijvoorbeeld. Gewoon de functies van je database gebruiken waarvoor ze bedoeld zijn. Ik gebruikte eerst ook timestamps maar je gaat het probleem verplaatsen naar je PHP code terwijl je dergelijke dingen direct kunt afhandelen in je query.

Als je perse in PHP een timestamp wilt hebben kun je altijd UNIX_TIMESTAMP(datum) in je SELECT gebruiken.

[Janoz]

Rian schreef op maandag 30 maart 2009 @ 11:16:
Misschien is het sowieso een idee om de datums in je database in vorm van een unix timestamp op te slaan. Persoonlijk vind ik dit veel prettiger. Bij het sorteren en zoeken op datums heb je dan ook geen problemen met de volgorde.

die problemen heb je ook niet wanneer je een datum type gebruikt. Je zult dus met betere argumenten moeten komen.

Argumenten tegen heb ik wel.
- Je database wordt onleesbaarder.
- Je kunt de ingebouwde datum functies niet meer gebruiken (zoeken of groeperen op jaar en maand bv)

Kortom, vertel mij eens waarom werken met een in een int/long opgeslagen timestamp in je database zoveel prettiger is dan een datum type.

[Erkens]

Janoz schreef op maandag 30 maart 2009 @ 12:44:
- Je kunt de ingebouwde datum functies niet meer gebruiken (zoeken of groeperen op jaar en maand bv)

Kortom, vertel mij eens waarom werken met een in een int/long opgeslagen timestamp in je database zoveel prettiger is dan een datum type.

Aangezien het in dit topic om mysql gaat: Als je het TIMESTAMP type gebruikt dan werken alle datum/tijd functies gewoon

[Janoz]

Ten eerste is het TIMESTAMP type een datum type. Ten tweede veranderd dit veld vaak automatisch en lijkt het me dus niet bedoeld om de datum van een event in op te slaan.

[Erkens]

Janoz schreef op maandag 30 maart 2009 @ 12:51:
Ten eerste is het TIMESTAMP type een datum type. Ten tweede veranderd dit veld vaak automatisch en lijkt het me dus niet bedoeld om de datum van een event in op te slaan.

Ik ging er vanuit dat jij die of niet kende aangezien jij het had over een int/long Uit deze post blijkt dat je die dus wel kent, althans de "oude" versie. Aangezien je tegenwoordig gewoon kan aangeven of je het auotmatisch wilt laten updaten (vreselijk irritant) en dat kan ook met een "DATE" veld.

[Janoz]

Ik ken hem wel, daarom heb ik ook expliciet aangegeven dat het om een in een int/long opgeslagen epoch ging. Dat is immers ook waar Rian het over heeft.

[Erkens]

Janoz schreef op maandag 30 maart 2009 @ 12:57:
Ik ken hem wel, daarom heb ik ook expliciet aangegeven dat het om een in een int/long opgeslagen epoch ging. Dat is immers ook waar Rian het over heeft.

* Erkens had de post van Rian niet goed gelezen
Dat is idd gewoon dom en biedt geen meerwaarde