Optioneel datum veld

Door Michel Bak op 25-10-2017 12:07

4.938 views

Ik heb een formulier met een optioneel einddatum veld.
In mijn database is de standaard waarde van einddatum NULL.

Wanneer ik mijn veld open laat wil ik dus dat de standaard waarde ingevuld wordt. Echter krijg ik de volgende melding steeds:

Er is iets mis gegeaan tijdens het invoeren van gegevens in de lidmaatschap database. klik hier om terug te keren en opnieuw te proberen. Incorrect date value: 'NULL' for column 'Datumeinde' at row 1.

De code die ik geschreven heb:

$einddatum = mysqli_real_escape_string ($connect, trim($_POST['einddatum']));
        
        if (empty($einddatum)){
        $einddatumfinal = "NULL";
        }else{
        $einddatum = explode('-', $_POST['einddatum']);
        $einddatumfinal = $einddatum[2].'-'.$einddatum[1].'-'.$einddatum[0];
        }

Wanneer ik $einddatumfinal = "NULL"; vervang door: $einddatumfinal = NULL; of door: return NULL;

Krijg ik nog steeds een foutmelding over de invoer in de database, waar gaat het fout?

- Ariën -

21-11-2017 11:41

De datum 09-02-2000 is ook niet een geldige datum voor een DATETIME-veld. Dit moet dan volgens de format YYYY-MM-DD geformuleerd worden. [php]Strtotime[/php] kan een hoop formaten herkennen, maar dit biedt geen zekerheid of iemand de datum in één van de herkende formaten invoert.

Het beste is om [php]checkdate[/php] te gebruiken. let er wel op dat deze de invoer volgens YYYY-MM-DD hanteert.

Thomas van den Heuvel

21-11-2017 13:32

Als je wilt voorkomen dat iemand mogelijk iets in het verkeerde formaat opgeeft, geef iemand dan in eerste instantie gewoon geen keuze. Gebruik dus een datepicker ofzo die alles (al dan niet onder water in een hidden field) direct in het juiste formaat zet.

Mogelijk bestaat er ook verwarring tussen de speciale (PHP-)waarde NULL en de (SQL-)string 'NULL'. Dit zijn twee compleet verschillende dingen. Mogelijk wordt e.e.a. correct vertaald wanneer je van prepared statements gebruik maakt maar de enige manier om te achterhalen wat er misgaat is het controleren van de uiteindelijke query die wordt uitgevoerd.

Helaas is daar volgens mij geen mogelijkheid toe met prepared statements binnen MySQLi (en prepared statements in PDO hoeven niet per se prepared statements te zijn zoals MySQL deze native ondersteunt). De enige manier is dan het loggen van queries en deze log vervolgens doorspitten. Daarom heb ik persoonlijk een hekel aan prepared statements, ik heb liever zelf de controle over de uiteindelijke vorm van mijn queries. Dit maakt het debuggen van queries een stuk eenvoudiger omdat je direct kunt zien wat je doet.

Reageren

Inloggen om te reageren