Ik heb een heel raar probleem. Ik heb 2 servers bij 2 verschillende webhosters staan. wanneer ik mijn administratiesysteem gebruik bij server 1 doet hij het wel, de datums worden goed weergegeven naar de database, niets aan de hand dus. Wanneer ik alles precies hetzelfde doe bij server 2 dan worden de datum's niet goed weergegeven. Alles wordt opgeslagen als 0000-00-00, 1970-01-01 of als 1999-11-30. Oke, dus ik probeer het zelf thuis via localhost. Installeer XAMPP en ik doe weer het zelfde als hiervoor. Nu krijg ik dus wederom die datum fout. Ik snap er niets van. Op 1 server werkt het wel en de andere 2 niet. Wat is hier tegen te doen, waar kan het aan liggen? Iemand een idee.
Sterker nog, er is nog helemaal niets betaald, het opslaan van de betaaldatum is dus zinloos. Een betaaltermijn is een business rule, en die kunnen zomaar veranderen. Wanneer je dit wilt opslaan, zou je in dit geval alleen de waarde 14 of 14 DAY willen opslaan. Even aanpassen naar 21 en je hebt een andere business rule zonder dat je met een datum hoeft te gaan klooien.
Maar hoevaak komt het voor dat je voor klant A andere betalingsregels hanteert dan voor klant B ? Dat maakt de boekhouding onnodig complex en levert veel extra financieele risico's op voor het bedrijf. Stel eventueel een handjevol regels op en verwijs per klant naar de bijbehorende regels. Om per klant andere regels op te stellen, dé manier om een faillisement "veilig" te stellen...
Het is afhankelijk van de op dat moment geldende instellingen hoe MySQL omgaat met een datum. En omdat zowel jij als de beheerder van de server deze instellingen runtime kunnen aanpassen, is het één groot feest in MySQL. Data die in de database staat, hoeft dus niet gelijk te zijn aan de data die jij wilde opslaan. Dit probleem speelt bij alle data in MySQL, maar vooral bij datums en tijden duikt dit probleem regelmatig op.
Ik heb hier eens iets over geschreven, zie dit artikel. Heb echter niet de illusie dat MySQL daarmee een veilige database wordt, dat is technisch niet mogelijk. Daar valt niks aan te doen.
Tip: Gebruik een DBMS die fouten afkeurt en niet zelf de nodige onzin gaat verzinnen.
Edit: De problemen verschillen ook nog weer per versie, iets wat werkt in versie 4, kan wel eens niet werken in versie 5 en andersom.
@pgFrank, ik wordt (kots) misselijk van je gevit op MySQL. Iedereen weet inmiddels dat SQLLite, PostgresQL etc. beter is, dit hoef je niet bij elk (lees: ELKE) erin te vermelden.
Als ik voor elke vermelding over 'hoe-slecht-MySQL-wel-niet-is' 1 cent zou krijgen, dan zou ik miljonair zijn!
SanThe
Geheel mee eens.
Een tijdje/keertje is leuk, maar dit is hoogst irritant aan het worden.
Ein-de-lijk ben ik niet de enige die Frank onderhand zat is met z'n anti-MySQLpropaganda! Nu hoor je het ook eens van een ander, Frank. Overigens:
(...) is het één groot feest in MySQL (...) Tip: Gebruik een DBMS die fouten afkeurt en niet zelf de nodige onzin gaat verzinnen.
+1
Ontopic:
Mag ik aannemen dat $sDatum de datum van vandaag bevat? Pak dan CURRENT_DATE en ga daarmee rekenen. Sla misschien in een apart veld nog eens '14' op, ten teken van het aantal dagen (termijn). Als je dan van 'business rule' wilt veranderen, kijk je gewoon welke records '14' hebben, reken het verschil uit tussen je nieuwe 'business rule' en de oude, en tel het verschil (aantal dagen) op bij de datum die opgeslagen staat ;-).
Yep, kill the messenger.... but don't shoot your problem!
Jongens, jullie kunnen wel gaan zeuren over mij, maar voorlopig laten jullie Paul al uren/dagen (zie voorgaande problemen) zwemmen met z'n huidige bugs. En wie veroorzaakt deze bugs? Precies, MySQL. Met een andere database was Paul al lang klaar geweest met z'n systeem, had dit hele probleem niet bestaan. Maar nee, ga maar zeuren over iemand die iets zinnigs heeft te melden, dat levert écht een oplossing op... -1 voor de MySQL-fanboys-zonder-oplossing.
Goed zo, Frank! Kijk maar eens wat je hebt aangericht met je gezanik. Overigens, je noemt ons nu MySQL-fanboys zonder enig argument. Als wij pleiten dat jij moet ophouden met je anti-MySQLpropaganda wil dat niet meteen zeggen dat wij MySQL helemaal toppie vinden. Nutteloze woorden, dus.
Daarnaast probeerde ik nog het een en ander op te lossen (zie mijn ontopic-gedeelte van mijn vorige post). De directe oplossing zou ik ook niet direct hebben, nee. Maar die heb jij ook niet, anders was Paul toch al klaar geweest? Goed zo... -2 voor postgreFrank.
Paul beschikt nu eenmaal niet over een andere database. Zoals zo velen. Maar postgreFrank wil dat niet zien geloof ik. Niet iedereen beschikt 1,2,3 over een 'database naar postgreFranks zin'.
Wat ik aanricht??? Hoe verzin je het! Ik wijs op de bugs van MySQL en nu zou ik Paul hebben doen schrikken? Gossie, ik wist niet dat ik over die powers beschikte.
En de oplossing van Djemo, dat is niet meer dan een copy-paste van de reacties van Blanche en mijzelf, dus om jezelf daarvoor nu een veer in je kont te steken... ;)
MySQL-gebruikers accepteren een onbetrouwbare database, prima, maar ga dan niet zeuren dat de database onbetrouwbaar is. Dat is een keuze die je zelf maakt. Er zijn genoeg alternatieven voor MySQL en dat is echt niet alleen PostgreSQL. Accepteer de onzin van MySQL of hou op met zeuren over de problemen die je er mee hebt. Het is dan ook een beetje zinloos om daar wéér een topic over aan te maken.
Wat ik aanricht??? Hoe verzin je het! Ik wijs op de bugs van MySQL en nu zou ik Paul hebben doen schrikken? Gossie, ik wist niet dat ik over die powers beschikte.
En de oplossing van Djemo, dat is niet meer dan een copy-paste van de reacties van Blanche en mijzelf, dus om jezelf daarvoor nu een veer in je kont te steken... ;)
MySQL-gebruikers accepteren een onbetrouwbare database, prima, maar ga dan niet zeuren dat de database onbetrouwbaar is. Dat is een keuze die je zelf maakt. Er zijn genoeg alternatieven voor MySQL en dat is echt niet alleen PostgreSQL. Accepteer de onzin van MySQL of hou op met zeuren over de problemen die je er mee hebt. Het is dan ook een beetje zinloos om daar wéér een topic over aan te maken.
My2Cents
Doen schrikken, kom op, get a life.
Moet ik misschien de code zo aanpassen dat ik de datum met een $POST schrijf naar de database?
Ik heb alles al geprobeerd maar het lukt niet.
edit: ik heb zojuist dit geprobeerd: '". date("Y-m-d", $datumfac) ."', maar dan zonder $datumfac en dan pakt hij wel de dag van vandaag. Dus het zit hem volgens mij in de invoer. Want als ik toch de bevenstaande waarde gebruik dan krijg ik deze datum: 30-11-1999
Moet ik misschien de code zo aanpassen dat ik de datum met een $POST schrijf naar de database?
Ik heb alles al geprobeerd maar het lukt niet.
Wanneer de datum uit een formulier komt, bv. een text-veld of select-box, dan gaat dat inderdaad met een $_POST. Bv. $_POST['jaar'], $_POST['maand'] en $_POST['dag']. Controleer eerst met checkdate() of het wel een geldige datum is, 2008-02-31 is geen geldige datum, en zet hem dan in de juiste volgorde:
<?
$datum = $_POST['jaar'].'-'.$_POST['maand'].'-'.$_POST['dag'];
?>
En wanneer het geen geldige datum is, geef je gewoon een foutmelding.
$datum kun je dan in je query gaan zetten, die is gecontroleerd en goedgekeurd.
