Fout in query: #1067 – Foutieve standaard waarde voor ‘created’
Fout in query: #1067 – Foutieve standaard waarde voor ‘created’
Ik werk lokaal en heb uiteindelijk XXAMPP opnieuw geïnstalleerd en ook de website. Helaas, de foutmelding blijft. Kan iemand mij helpen?
Met vriendelijke groet, Dick
https://stackoverflow.com/questions/36882149/error-1067-42000-invalid-default-value-for-created-at
- Ariën - op 01/02/2022 12:55:51:
Op welk OS draai je? Het lijkt erop dat je database corrupt is?
Toevoeging op 01/02/2022 14:07:44:
Op Windows 10
Bijvoorbeeld "" voor een integer, of voor een datetime.
of NULL als default waarde, maar dan NOT-NULL bij de eigenschappen.
Ik schat in dat je kolom Created een datetime of ander soort timestamp is,
je die niet invult in de insert query, en dat je database zich nu afvraagt hoe hij een lege string in een datetime moet omzetten.
Dat, al dan niet in combinatie met een trigger die niet afgaat:
je kunt ook een trigger op het inserten zetten, die in zo'n geval created = now() doet.
(zou niet de eerste zijn die bij het verhuizen van een site de triggers of stored-procedures niet meepakt)
Toevoeging op 01/02/2022 15:11:57:
En uit het voorbeeld van Adoptive's link:
0000-00-00 is geen valide datum. Ook daar zou iets zinnigs als NOW() in moeten, of je moet NULL accepteren als waarde.
- Ariën - op 01/02/2022 14:57:55:
Heb je de link met mogelijke oplossingen al bekeken?
Toevoeging op 01/02/2022 16:04:03:
Ik ben de suggesties aan het proberen. Ik probeer "NO_ZERO_IN_DATE,NO_ZERO_DATE" weh te halen maar dat lukt nog niet. Ik heb niet veel ervaring met PHP.
Toevoeging op 01/02/2022 16:06:42:
Ivo P op 01/02/2022 15:09:52:
Oudere versies van MySQL of MariaDB accepteerden soms rare default waarden.
Bijvoorbeeld "" voor een integer, of voor een datetime.
of NULL als default waarde, maar dan NOT-NULL bij de eigenschappen.
Ik schat in dat je kolom Created een datetime of ander soort timestamp is,
je die niet invult in de insert query, en dat je database zich nu afvraagt hoe hij een lege string in een datetime moet omzetten.
Dat, al dan niet in combinatie met een trigger die niet afgaat:
je kunt ook een trigger op het inserten zetten, die in zo'n geval created = now() doet.
(zou niet de eerste zijn die bij het verhuizen van een site de triggers of stored-procedures niet meepakt)
Toevoeging op 01/02/2022 15:11:57:
En uit het voorbeeld van Adoptive's link:
0000-00-00 is geen valide datum. Ook daar zou iets zinnigs als NOW() in moeten, of je moet NULL accepteren als waarde.
Bijvoorbeeld "" voor een integer, of voor een datetime.
of NULL als default waarde, maar dan NOT-NULL bij de eigenschappen.
Ik schat in dat je kolom Created een datetime of ander soort timestamp is,
je die niet invult in de insert query, en dat je database zich nu afvraagt hoe hij een lege string in een datetime moet omzetten.
Dat, al dan niet in combinatie met een trigger die niet afgaat:
je kunt ook een trigger op het inserten zetten, die in zo'n geval created = now() doet.
(zou niet de eerste zijn die bij het verhuizen van een site de triggers of stored-procedures niet meepakt)
Toevoeging op 01/02/2022 15:11:57:
En uit het voorbeeld van Adoptive's link:
0000-00-00 is geen valide datum. Ook daar zou iets zinnigs als NOW() in moeten, of je moet NULL accepteren als waarde.
Toevoeging op 01/02/2022 16:09:16:
Ik heb bij created inderdaad staan: created datetime Nee 0000-00-00 00:00:00.
Verder: sql_mode: NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Heb je wellicht een concreet commando ter verbetering?
Toevoeging op 01/02/2022 16:10:21:
Ivo P op 01/02/2022 15:09:52:
Oudere versies van MySQL of MariaDB accepteerden soms rare default waarden.
Bijvoorbeeld "" voor een integer, of voor een datetime.
of NULL als default waarde, maar dan NOT-NULL bij de eigenschappen.
Ik schat in dat je kolom Created een datetime of ander soort timestamp is,
je die niet invult in de insert query, en dat je database zich nu afvraagt hoe hij een lege string in een datetime moet omzetten.
Dat, al dan niet in combinatie met een trigger die niet afgaat:
je kunt ook een trigger op het inserten zetten, die in zo'n geval created = now() doet.
(zou niet de eerste zijn die bij het verhuizen van een site de triggers of stored-procedures niet meepakt)
Toevoeging op 01/02/2022 15:11:57:
En uit het voorbeeld van Adoptive's link:
0000-00-00 is geen valide datum. Ook daar zou iets zinnigs als NOW() in moeten, of je moet NULL accepteren als waarde.
Bijvoorbeeld "" voor een integer, of voor een datetime.
of NULL als default waarde, maar dan NOT-NULL bij de eigenschappen.
Ik schat in dat je kolom Created een datetime of ander soort timestamp is,
je die niet invult in de insert query, en dat je database zich nu afvraagt hoe hij een lege string in een datetime moet omzetten.
Dat, al dan niet in combinatie met een trigger die niet afgaat:
je kunt ook een trigger op het inserten zetten, die in zo'n geval created = now() doet.
(zou niet de eerste zijn die bij het verhuizen van een site de triggers of stored-procedures niet meepakt)
Toevoeging op 01/02/2022 15:11:57:
En uit het voorbeeld van Adoptive's link:
0000-00-00 is geen valide datum. Ook daar zou iets zinnigs als NOW() in moeten, of je moet NULL accepteren als waarde.
Dick VanBruggen op 01/02/2022 16:01:56:
Ik heb bij created inderdaad staan: created datetime Nee 0000-00-00 00:00:00.
En als je daar eens 1970-01-01 00:00:00 van maakt?
Toevoeging op 01/02/2022 16:38:25:
als zou ik de voorkeur hebben voor Default = NULL (en dan ook allow null op Ja zetten)
Controleer of de defaultwaarde het probleem is met SQL:
Code (php)
1
2
2
INSERT INTO `<tabelnaam>` (`<kolom1>`, `<kolom2>`, `created`)
VALUES '<waarde1>', '<waarde2>', '<zinnige waarde voor kolom created>';
VALUES '<waarde1>', '<waarde2>', '<zinnige waarde voor kolom created>';
Als er dan geen melding verschijnt bij die query, kan je er vanuitgaan dat het probleem in de metadata van de tabel zit.
Fix:
Code (php)
1
ALTER TABLE `<tabelnaam>` ALTER COLUMN `created` DROP DEFAULT;
Maar in plaats van het weghalen kan je ook een zinnige default aan created toekennen:
Code (php)
1
ALTER TABLE `<tabelnaam>` ALTER COLUMN `created` SET CURRENT_DATE();
Of CURRENT_TIMESTAMP() als het datatype geen datum is maar datumtijd.
Een aantal waar ik niet verder mee kwam:
- Als ik 1970-01-01 00:00:00 probeer in te vullen krijg ik zelfde foutmelding voor een volgende rij met 'datetime'.
- Bij het maken van een nieuwe rij komt bij opslaan dezelfde foutmelding.
- ALTER TABLE `jos_content` ALTER COLUMN `created` SET_CURRENT_TIMESTAMP(1970-01-01 00:00:00); Werkt helaas niet!
Waar ik wel verder mee kom is het volgende:
show variables like 'sql_mode' ;
geeft als resultaat:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
sql_mode NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Ik voer nu eerst uit:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen en vervolgens:
SET GLOBAL sql_mode = 'NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
zodat de setting gelijk wordt aan de live site.
Ik nu nog twee vragen:
1. Kan er iets verkeerd gaan met de settings die ik gedaan heb? Ik overzie niet echt wat het resultaat is.
2. Ik heb de wijzigingen aangebracht via de tab SQL in phpMyAdmin. Dat betekent dat bij het opnieuw opstarten van XAMPP de wijzigingen verdwenen zijn. Kan ik “ergens” de SQL-opdrachten aanbrengen zodat deze automatisch worden uitgevoerd?
Groet, Dick
Je kan de SQL-mode ook in my.cnf aanpassen.
Dan werkt het globaal zonder dat je dit handmatig moet toevoegen.
Vergeet niet hierna MySQL/MariaDB te herstarten.
Gewijzigd op 04/02/2022 18:49:17 door - Ariën -
Dick VanBruggen op 04/02/2022 18:42:08:
- ALTER TABLE `jos_content` ALTER COLUMN `created` SET_CURRENT_TIMESTAMP(1970-01-01 00:00:00); Werkt helaas niet!
Waar ik wel verder mee kom is het volgende:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen
Waar ik wel verder mee kom is het volgende:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen
Je moet zo'n waarde natuurlijk wel tussen enkele aanhalingstekens zetten, anders krijg je een fout vanwege de ongeldigde literal: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html
Daarbij accepteert de functie CURRENT_TIMESTAMP() geen tijdstempel als argument, maar het aantal decimalen voor de precisie: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
En je kunt met de SQL mode van MySQL vanalles in de war krijgen. Je hebt niet de hele lijst van instellingen gepost, maar het lijkt er op dat je de data zelf niet onder controle hebt door ongeldige data toe staan (met het weghalen van de opties die je hebt genoemd).
Als ik jou was, zou ik me nog wat meer verdiepen in MySQL, want je weet nog niet helemaal wat je aan het doen bent.
- Ariën - op 04/02/2022 18:48:30:
Ik liep er toevallig gisteren ook tegenaan bij het herinstalleren van een server.
Je kan de SQL-mode ook in my.cnf aanpassen.
Dan werkt het globaal zonder dat je dit handmatig moet toevoegen.
Vergeet niet hierna MySQL/MariaDB te herstarten.
Je kan de SQL-mode ook in my.cnf aanpassen.
Dan werkt het globaal zonder dat je dit handmatig moet toevoegen.
Vergeet niet hierna MySQL/MariaDB te herstarten.
Toevoeging op 04/02/2022 22:40:45:
- Ariën - op 04/02/2022 18:48:30:
Ik liep er toevallig gisteren ook tegenaan bij het herinstalleren van een server.
Je kan de SQL-mode ook in my.cnf aanpassen.
Dan werkt het globaal zonder dat je dit handmatig moet toevoegen.
Vergeet niet hierna MySQL/MariaDB te herstarten.
Je kan de SQL-mode ook in my.cnf aanpassen.
Dan werkt het globaal zonder dat je dit handmatig moet toevoegen.
Vergeet niet hierna MySQL/MariaDB te herstarten.
Is my.cnf een bestaande file en waar vind ik die of moet ik die zelf aanmaken.
Kan je ook nog zeggen of mijn aanpassingen andere problemen kunnen geven?
Ad Fundum op 04/02/2022 19:38:57:
Je moet zo'n waarde natuurlijk wel tussen enkele aanhalingstekens zetten, anders krijg je een fout vanwege de ongeldigde literal: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html
Daarbij accepteert de functie CURRENT_TIMESTAMP() geen tijdstempel als argument, maar het aantal decimalen voor de precisie: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
En je kunt met de SQL mode van MySQL vanalles in de war krijgen. Je hebt niet de hele lijst van instellingen gepost, maar het lijkt er op dat je de data zelf niet onder controle hebt door ongeldige data toe staan (met het weghalen van de opties die je hebt genoemd).
Als ik jou was, zou ik me nog wat meer verdiepen in MySQL, want je weet nog niet helemaal wat je aan het doen bent.
Dick VanBruggen op 04/02/2022 18:42:08:
- ALTER TABLE `jos_content` ALTER COLUMN `created` SET_CURRENT_TIMESTAMP(1970-01-01 00:00:00); Werkt helaas niet!
Waar ik wel verder mee kom is het volgende:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen
Waar ik wel verder mee kom is het volgende:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen
Je moet zo'n waarde natuurlijk wel tussen enkele aanhalingstekens zetten, anders krijg je een fout vanwege de ongeldigde literal: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html
Daarbij accepteert de functie CURRENT_TIMESTAMP() geen tijdstempel als argument, maar het aantal decimalen voor de precisie: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
En je kunt met de SQL mode van MySQL vanalles in de war krijgen. Je hebt niet de hele lijst van instellingen gepost, maar het lijkt er op dat je de data zelf niet onder controle hebt door ongeldige data toe staan (met het weghalen van de opties die je hebt genoemd).
Als ik jou was, zou ik me nog wat meer verdiepen in MySQL, want je weet nog niet helemaal wat je aan het doen bent.
Bij de SET GLOBAL sql_mode opdracht heb ik quotes gebruikt maar bij de resultaten, die ik weergeef, staan ze niet.
Overigens bedankt voor de uitgebreide informatie. Het toont aan dat er een wereld van informatie achter PHP schuil gaat. Ik weet inderdaad nog niet veel van PHP daarom heb ik de instellingen van de live site overgenomen, die geen foutmelding geeft. In deze fase van mijn website ben ik op dit moment meer gericht op de oplossing van de foutmelding dan dat ik mij nu uitgebreid in PHP ga verdiepen.
Toevoeging op 05/02/2022 00:16:00:
- Ariën - op 04/02/2022 22:44:25:
Ja, het is een bestaande file.
En waar vind ik die? Je houdt het spannend :)
Toevoeging op 05/02/2022 17:34:26:
Dick VanBruggen op 04/02/2022 23:23:00:
Bij de SET GLOBAL sql_mode opdracht heb ik quotes gebruikt maar bij de resultaten, die ik weergeef, staan ze niet.
Overigens bedankt voor de uitgebreide informatie. Het toont aan dat er een wereld van informatie achter PHP schuil gaat. Ik weet inderdaad nog niet veel van PHP daarom heb ik de instellingen van de live site overgenomen, die geen foutmelding geeft. In deze fase van mijn website ben ik op dit moment meer gericht op de oplossing van de foutmelding dan dat ik mij nu uitgebreid in PHP ga verdiepen.
Toevoeging op 05/02/2022 00:16:00:
En waar vind ik die? Je houdt het spannend :)
Ad Fundum op 04/02/2022 19:38:57:
Je moet zo'n waarde natuurlijk wel tussen enkele aanhalingstekens zetten, anders krijg je een fout vanwege de ongeldigde literal: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html
Daarbij accepteert de functie CURRENT_TIMESTAMP() geen tijdstempel als argument, maar het aantal decimalen voor de precisie: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
En je kunt met de SQL mode van MySQL vanalles in de war krijgen. Je hebt niet de hele lijst van instellingen gepost, maar het lijkt er op dat je de data zelf niet onder controle hebt door ongeldige data toe staan (met het weghalen van de opties die je hebt genoemd).
Als ik jou was, zou ik me nog wat meer verdiepen in MySQL, want je weet nog niet helemaal wat je aan het doen bent.
Dick VanBruggen op 04/02/2022 18:42:08:
- ALTER TABLE `jos_content` ALTER COLUMN `created` SET_CURRENT_TIMESTAMP(1970-01-01 00:00:00); Werkt helaas niet!
Waar ik wel verder mee kom is het volgende:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen
Waar ik wel verder mee kom is het volgende:
sql_mode NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTIO...
Ik heb ook een live site waar fout #1067 niet optreedt. Daar krijg ik:
SET GLOBAL sql_mode = '';
De foutmelding is nu verdwenen
Je moet zo'n waarde natuurlijk wel tussen enkele aanhalingstekens zetten, anders krijg je een fout vanwege de ongeldigde literal: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html
Daarbij accepteert de functie CURRENT_TIMESTAMP() geen tijdstempel als argument, maar het aantal decimalen voor de precisie: https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_current-timestamp
En je kunt met de SQL mode van MySQL vanalles in de war krijgen. Je hebt niet de hele lijst van instellingen gepost, maar het lijkt er op dat je de data zelf niet onder controle hebt door ongeldige data toe staan (met het weghalen van de opties die je hebt genoemd).
Als ik jou was, zou ik me nog wat meer verdiepen in MySQL, want je weet nog niet helemaal wat je aan het doen bent.
Bij de SET GLOBAL sql_mode opdracht heb ik quotes gebruikt maar bij de resultaten, die ik weergeef, staan ze niet.
Overigens bedankt voor de uitgebreide informatie. Het toont aan dat er een wereld van informatie achter PHP schuil gaat. Ik weet inderdaad nog niet veel van PHP daarom heb ik de instellingen van de live site overgenomen, die geen foutmelding geeft. In deze fase van mijn website ben ik op dit moment meer gericht op de oplossing van de foutmelding dan dat ik mij nu uitgebreid in PHP ga verdiepen.
Toevoeging op 05/02/2022 00:16:00:
- Ariën - op 04/02/2022 22:44:25:
Ja, het is een bestaande file.
En waar vind ik die? Je houdt het spannend :)
Ik heb inmiddels gevonden dat in xampp\mysql\bin de file my.ini staat met de opdracht voor de mode setting. Die heb ik gewijzigd en wordt nu automatisch uitgevoerd bij het opstarten van XAMPP.
Mocht je je later wat meer willen verdiepen, dan is het handig om te weten dat MySQL geen PHP is, maar een database welke vaak wordt gecombineerd met PHP.
Een aantal MySQL tutorials:
- https://dev.mysql.com/doc/refman/8.0/en/tutorial.html (Engelstalig)
- https://www.strato.nl/server/mysql-tutorial/
- https://www.w3schools.com/mySQl/default.asp (Engelstalig)
Succes!
Ad Fundum op 05/02/2022 19:00:20:
De foutmelding is eigenlijk een waarschuwing van de database zodat het geen ongeldige gegevens opslaat. Als je alleen die melding verhelpt krijg je (gedeeltelijk) ongeldige gegevens. Daarmee span je het paard achter de wagen.
Mocht je je later wat meer willen verdiepen, dan is het handig om te weten dat MySQL geen PHP is, maar een database welke vaak wordt gecombineerd met PHP.
Een aantal MySQL tutorials:
- https://dev.mysql.com/doc/refman/8.0/en/tutorial.html (Engelstalig)
- https://www.strato.nl/server/mysql-tutorial/
- https://www.w3schools.com/mySQl/default.asp (Engelstalig)
Succes!
Mocht je je later wat meer willen verdiepen, dan is het handig om te weten dat MySQL geen PHP is, maar een database welke vaak wordt gecombineerd met PHP.
Een aantal MySQL tutorials:
- https://dev.mysql.com/doc/refman/8.0/en/tutorial.html (Engelstalig)
- https://www.strato.nl/server/mysql-tutorial/
- https://www.w3schools.com/mySQl/default.asp (Engelstalig)
Succes!
Dank voor de links.
Begrijp ik uit jouw reactie dat het toch nog fout kan zitten ondanks dat de foutmelding verdwenen is? Het overnemen van de settings van de host leek mij een goede actie maar ... toch niet?
In mijn auto krijg ik op het moment steeds een melding over mijn linkerachteruitrijlicht. Die doet het echter gewoon.
Een oplossing zou zijn: foutmeldingen uitzetten. En de melding dat ik harder rij dan de maximumsnelheid is misschien ook niet boeiend.
Kortom: alle meldingen gewoon uit.
Alleen jammer als dan ook geen melding komt over problemen met de remdruk of de olie in de motor.
Zo ook voor je database.
Het verschil tussen lege string, 0 en NULL is misschien niet zo heel spannend. En als je "0000-00-00" invult en je database maakt daar zelf null van, of jouw applicatie snapt dat dat staat voor "niet ingevuld", dan loopt dat wel los.
Maar als je er na eem doorlooptijd van 2 maanden achter komt dat je van 5000 bestellingen die jouw fabriek heeft gemaakt, je nu geen idee meer hebt voor welke klanten dat was omdat jouw applicatie ergens een klant_id had moeten invullen (integer) maar probeerde om de naam van de klant daar neer te zetten.
En je database stond in de mode 'als er "jansen" in dit veld geplaatst wordt, maak daar dan maar "0" van'
Kortom: fouten onderdrukken kan best. Maar je lost liever de fout op dan dat je je hoofd in het zand steekt.
MySQL kan ook 'gewoon' ongeldige data opslaan, zoals '2022-02-29'.