[MySQL] simpele SQL query? *

[Verwijderd]

Op mijn homepage doe ik geloof ik een simpele query, maar het gaat niet helemaal volgens plan:

SELECT agenda_tekst FROM agenda WHERE agenda_archief <> 'j' AND agenda_home = 'j' ORDER BY agenda_datum

De bedoeling is dat hij alleen de agendapunten laat zien waar agenda_home is aangevinkt, en waar dan altijd een j voor in de MySQL database zit. Dit gaat overigens goed.

Nu heb ik de agenda uitgebreid met een archief. Dus als archief is aangevinkt, komt er ook op die plaats een j in de database. In mijn SQL-statement wil ik de agendapunten niet meer laten zien als er een j staat bij agenda_archief. Maar omdat ik deze functie later heb toegevoegd, zijn alle agenda_archief velden nu nog leeg. Hoewel ik probeer te doen "laat niets zien als agenda_archief niet gelijk is aan j", laat ie nu helemaal niets meer zien, ook al zijn de velden gewoon leeg en niet gelijk aan 'j' dus? Wat is wrong?

[it0]

Als iets niet j is, is het dan een NULL of een andere letter, in geval van het eerste geval zal het wel fout gaan..

[Verwijderd]

Voer deze update-query eerst uit:

code:

UPDATE TABLE jouwtabel
SET Archief = 'n'

Daarna werkt hij volgens mij wel.
Moet je wel bij je Agenda progamma zorgen dat als je een nieuw record aanmaakt archief dan op 'n' komt te staan.

Probeer zoveel mogelijk te vermijden om NULL values in je db te hebben of zelfs eigenlijk gewoon zorgen dat ze er helemaal niet zijn.

[ Voor 42% gewijzigd door Verwijderd op 21-01-2004 14:01 ]

[curry684]

pssst.... ***** Lees dit! Over topictitels in P&W *****

[bras]

zoiets als aanpassing op de query?

WHERE (agenda_acrhief IS NULL OR agenda_archief <> 'j' )
AND agenda_home = 'j'

[ Voor 22% gewijzigd door bras op 21-01-2004 13:58 ]

[Verwijderd]

ehhh okay curry


Ja, als het niet 'j' is dan is het nog leeg.

Als ik ga updaten zorg ik ervoor dat er nu wel een 'n' komt te staan, en dan werkt het wel.

Yep, als ik overal 'n' zet dan werkt het wel.

Maar ik vind het toch raar, als ik nou zeg alleen maar 'j' en de rest niet, dat een NULL dan toch ook mee gaat

[ Voor 57% gewijzigd door Verwijderd op 21-01-2004 14:09 ]

[Verwijderd]

Verwijderd schreef op 21 januari 2004 @ 14:01:
ehhh okay curry


Ja, als het niet 'j' is dan is het nog leeg.

Als ik ga updaten zorg ik ervoor dat er nu wel een 'n' komt te staan, en dan werkt het wel.

Yep, als ik overal 'n' zet dan werkt het wel.

Maar ik vind het toch raar, als ik nou zeg alleen maar 'j' en de rest niet, dat een NULL dan toch ook mee gaat

//edit//
'kzal die query hierboven eens proberen ja

Komt omdat NULL geen definitie heeft, het is echt NIETS, het is geen char, geen int, geen float.... etc. dus de vergelijk of hij 'j' is kan hij niet maken. Dus hij kan niet testen of er een 'j' staat als de waarde NULL in het veld staat.

grappige maar wel duidelijke uitleg:
als je 'n' in je database hebt staan en je vergelijkt het met een 'j' dan ben je dus appels met peren aan het vergelijken. (is dus FALSE)

als je 'j' in je database hebt staan en je vergelijkt het met een 'j' dan ben je dus appels met appels aan het vergelijken. (is dus TRUE)

als je NULL in je database hebt staan en je vergelijkt het met een 'j' dan ben je dus appels met eh... ja.... precies... met NIETS aan het vergelijken. (is dus FALSE)

[ Voor 29% gewijzigd door Verwijderd op 21-01-2004 14:10 ]

[Verwijderd]

Okay, hij doet het! Bras e.a. ... thanks!

Ik had zelf wel = '' en = NULL geprobeerd, maar IS NULL doet het hem!

[Verwijderd]

Verwijderd schreef op 21 januari 2004 @ 14:06:

grappige maar wel duidelijke uitleg:
als je 'n' in je database hebt staan en je vergelijkt het met een 'j' dan ben je dus appels met peren aan het vergelijken. (is dus FALSE)

als je 'j' in je database hebt staan en je vergelijkt het met een 'j' dan ben je dus appels met appels aan het vergelijken. (is dus TRUE)

als je NULL in je database hebt staan en je vergelijkt het met een 'j' dan ben je dus appels met eh... ja.... precies... met NIETS aan het vergelijken. (is dus FALSE)

Oow, ik zie nu 2 keer FALSE staan en dat is precies wat ik hebben wilden, want ik zei <> 'j' oftewel dan wordt je laatste argument TRUE ja ik weet het ik ben kopping

Maar in MySQL staat er wel een char(1) gedefinieerd, en ik blijf het toch raar vinden als ik zeg "hij mag alleen maar 'j' zijn" oftewel een appel, dat hij dan NIETS toch goed rekent

Ik programmeer in elk geval al een tijdje en ik dacht hier voorheen nog geen last van gehad te hebben... Of ik was dit nog niet tegengekomen alleen ik dacht van wel

[Verwijderd]

Nou heb ik weer een soortgelijk probleem, maar dan met een leeg datumveld.

Ik heb namelijk als optie een datumveld aan een tabel toegevoegd, waarin een datum kan worden opgegeven, of een datum niet hoeft te worden opgegeven, oftewel leeg blijft.

Als ik nu records upload waarbij geen datum is opgegeven, dan SET ik de datum als volgt: datum = ''

Thuis op mijn MS Access database kan ik dan selecteren met WHERE datum = '', maar op de MySQL webserver lukt dat niet, dan moet ik selecteren met WHERE datum = '0000-00-00', want dat maakt MySQL er blijkbaar van.

Is er toevallig ook een mogelijkheid om de nulwaarde van een datum in MS Access op dezelfde manier te zetten of te selecteren als in MySQL? Want ik moet nu 2 soorten webpagina's hebben, 1 voor Access en 1 voor MySQL, da's niet handig

[ Voor 15% gewijzigd door Verwijderd op 22-01-2004 13:14 ]

[Verwijderd]

Want ik moet nu 2 soorten webpagina's hebben, 1 voor Access en 1 voor MySQL, da's niet handig

2 databases ? waarom eigenlijk ??


maar goed:
Kun je niet gewoon checken dat de waarde van datum niet:

false,
0,
0000-00-00

is ? dan dek je toch alles af

[ Voor 37% gewijzigd door Verwijderd op 22-01-2004 15:35 ]

[Verwijderd]

Ik zit eerst thuis op Access te ontwikkelen, dat vind ik veel makkelijker en sneller werken. Daarna zet ik hem online in MySQL, vandaar.

Anyway, als ik op alles check krijg ik errors in zowel MySQL als in Access, een leeg datumveld wordt blijkbaar toch heel anders geinterpreteerd...

Misschien nou eindelijk wel eens een goed moment om MySQL er thuis ook maar op te knallen en Ms Access eraf te gooien. Ik vind alleen die front-end van Access zo makkelijk werken, nog tips voor een Windows XP MySQL frontje?

[Johnny]

Verwijderd schreef op 22 januari 2004 @ 16:29:
Misschien nou eindelijk wel eens een goed moment om MySQL er thuis ook maar op te knallen en Ms Access eraf te gooien. Ik vind alleen die front-end van Access zo makkelijk werken, nog tips voor een Windows XP MySQL frontje?

PHPmyadmin

Werkt wel via een webinterface, maar heeft als voordeel dat je er dan ook weer vanaf iedere locatie bij kan.

[Xenon]

Verwijderd schreef op 22 januari 2004 @ 16:29:
Ik zit eerst thuis op Access te ontwikkelen, dat vind ik veel makkelijker en sneller werken. Daarna zet ik hem online in MySQL, vandaar.

Anyway, als ik op alles check krijg ik errors in zowel MySQL als in Access, een leeg datumveld wordt blijkbaar toch heel anders geinterpreteerd...

Misschien nou eindelijk wel eens een goed moment om MySQL er thuis ook maar op te knallen en Ms Access eraf te gooien. Ik vind alleen die front-end van Access zo makkelijk werken, nog tips voor een Windows XP MySQL frontje?

Navicat, the best a man can get

[pistole]

Verwijderd schreef op 21 januari 2004 @ 13:56:
(...)Probeer zoveel mogelijk te vermijden om NULL values in je db te hebben of zelfs eigenlijk gewoon zorgen dat ze er helemaal niet zijn.

Pourquois (waarom)?

NULLs in je database zijn zeker wel zinvol, want... het betekent dat er geen gegevens zijn. Liever een NULL dan een '' of "1900-01-01".
Je moet er alleen op de juiste manier mee om weten te gaan...

[ Voor 10% gewijzigd door pistole op 22-01-2004 21:17 ]

[Verwijderd]

Weet jij dan misschien de juiste manier om een lege datum in zowel MySQL als MS Access aan te roepen?

Ben nu navicat trial aan het downloaden trouwens

[Verwijderd]

Navicat ziet er erg gelikt uit! Ik gebruik nu DBTools om mijn MySQL op afstand te beheren, kan je ook makkelijk mee van MS Access naar MySQL heen en weer, maar dit ziet er veel mooier uit!

Om mijn database te backuppen, gebruikte ik eerst altijd de combi DUMP (.sql file) en LOAD (execute batch file).

Maar in Navicat zie ik ook nog een aparte backup/restore mogelijkheid hier. Is dat een betere combi dan de DUMP/LOAD? Ik kan bijvoorbeeld niet zien wat erin komt te zitten als ik "backup" uitvoer... Alle databases? En waar komen de backups terecht? Nou ja even wennen nog, wel leuk, MS Access goodbye zeggen

[ Voor 50% gewijzigd door Verwijderd op 23-01-2004 03:14 ]

[Verwijderd]

Verwijderd schreef op 21 januari 2004 @ 14:29:
[...]


Oow, ik zie nu 2 keer FALSE staan en dat is precies wat ik hebben wilden, want ik zei <> 'j' oftewel dan wordt je laatste argument TRUE ja ik weet het ik ben kopping

Maar in MySQL staat er wel een char(1) gedefinieerd, en ik blijf het toch raar vinden als ik zeg "hij mag alleen maar 'j' zijn" oftewel een appel, dat hij dan NIETS toch goed rekent

Ik programmeer in elk geval al een tijdje en ik dacht hier voorheen nog geen last van gehad te hebben... Of ik was dit nog niet tegengekomen alleen ik dacht van wel

Nee, dan is de uitkomst nog steeds false! IETS vergelijken met NIETS is ALTIJD false. Of je nou vergelijkt of ze hetzelfde zijn (=), of juist niet (<>) maakt niet uit.

[ Voor 6% gewijzigd door Verwijderd op 23-01-2004 13:15 ]

[Verwijderd]

Okee, duidelijk!

Nu die lege datums nog

[Verwijderd]

Verwijderd schreef op 23 januari 2004 @ 14:39:
Okee, duidelijk!

Nu die lege datums nog

Inderdaad, MySQL slaat inderdaad een lege datum ('') op als 0000-00-00.

Wat ik doe om te zorgen dat ik wel echt de waarde '' als waarde op kan slaan in de database is de column datum te definieren als een char(12), dan kan ik er een datum in opslaan en ook een lege string ('').

Maar dan moet je natuurlijk wel vanuit je programma wel zorgen dat die datum altijd klopt, want MySQL geeft dan geen error meer bij een ongeldige datum.

Maar om dat op te lossen gebruik ik altijd date-time pickers in mijn applicaties, dan kun je dus nooit een verkeerde datum hebben. (datum aanklikken i.p.v. intypen)

Ik hoop je een beetje geholpen te hebben.

[Verwijderd]

Ja klopt, daar had ik ook al aan gedacht.

Maar ik heb dat idee maar laten varen omdat ik ongeveer 40 date/time functies tot mijn beschikking heb, en dat is soms wel makkelijk. Bijvoorbeeld de huidige datum en tijd direct in zo'n dateveld kunnen gooien, of berekeningen met de datum doen, bijvoorbeeld doe iets met de datum 3 maanden later ofzo...

Maar goed, dat is denk ik ook wel allemaal met chars te doen, en als je de datum maar gewoon op de Amerikaanse manier (2004-01-24) in laat voeren (bijv. met pulldowns), kan je wel altijd blijven sorteren en de losse jaren, maanden, dagen converteren naar getallen en dan ermee rekenen, toch?

Hmmpf, volgens mij krijg ik wel nu automatisch een foutmelding als ik bijvoorbeeld 30 februari in een echt datumveld probeer te pleuren, met een char moet ik dat dan weer gaan afvangen!

Maar het blijft altijd een lastig gedoe met die datumvelden!

[Verwijderd]

Maar goed, dat is denk ik ook wel allemaal met chars te doen, en als je de datum maar gewoon op de Amerikaanse manier (2004-01-24) in laat voeren (bijv. met pulldowns), kan je wel altijd blijven sorteren en de losse jaren, maanden, dagen converteren naar getallen en dan ermee rekenen, toch?

Zover ik weet wel ja, een datum is gewoon een string die aan een paar eisen voldoet. Dus een veld waar een datum in staat als een char(12) of een veld waar dezelfde datum instaat als een smalldate zijn exact hetzelfde te gebruiken. Alleen de check of het een geldige datum is heb je niet.

[Verwijderd]

>>>Alleen de check of het een geldige datum is heb je niet.

Nou, je kan natuurlijk wel eerst een datecheck doen met een datumfunctie en de invoer daarna gewoon in de char stoppen!

Ik denk dat ik het maar eens een keertje ga proberen, want met die echte datums heb ik altijd gedoe!

Alleen als er ook nog een tijd bij moet wordt het wel een beetje teveel van het goede denk ik, want dan moet je met 5 stukken gaan werken...