Fout in query: #1067 – Foutieve standaard waarde voor ‘created’

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Dick VanBruggen

Dick VanBruggen

01/02/2022 12:45:05
Quote Anchor link
Bij bijna alle database bewerkingen die ik doe krijg ik de foutmelding:

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
 
PHP hulp

PHP hulp

27/06/2022 17:44:32
 
- Ariën  -
Beheerder

- Ariën -

01/02/2022 12:55:51
Quote Anchor link
Op welk OS draai je? Het lijkt erop dat je database corrupt is?
 
Adoptive Solution

Adoptive Solution

01/02/2022 13:39:04
 
Dick VanBruggen

Dick VanBruggen

01/02/2022 14:07:28
Quote Anchor link
- 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
 
- Ariën  -
Beheerder

- Ariën -

01/02/2022 14:57:55
Quote Anchor link
Heb je de link met mogelijke oplossingen al bekeken?
 
Ivo P

Ivo P

01/02/2022 15:09:52
Quote Anchor link
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.
 
Dick VanBruggen

Dick VanBruggen

01/02/2022 16:01:56
Quote Anchor link
- 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.




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.
 
Ivo P

Ivo P

01/02/2022 16:37:42
Quote Anchor link
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)
 
Ad Fundum

Ad Fundum

02/02/2022 15:14:56
Quote Anchor link
Waar je naar kan kijken is of de default waarde van de kolom created van de tabel waar je mee bezig bent niet het probleem is. Als je een regel aan de tabel toevoegt, en je noemt de kolom created niet, pakt de database de waarde die is opgeslagen in de metadata van de tabel. En als dat een ongeldige waarde is, kan het zijn dat je die melding krijgt (dat acht ik waarschijnlijk voor MySQL en MariaDB).

Controleer of de defaultwaarde het probleem is met SQL:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
INSERT INTO `<tabelnaam>` (`<kolom1>`, `<kolom2>`, `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)
PHP script in nieuw venster Selecteer het PHP script
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)
PHP script in nieuw venster Selecteer het PHP script
1
ALTER TABLE `<tabelnaam>` ALTER COLUMN `created` SET CURRENT_DATE();

Of CURRENT_TIMESTAMP() als het datatype geen datum is maar datumtijd.
Gewijzigd op 02/02/2022 15:17:56 door Ad Fundum
 
Dick VanBruggen

Dick VanBruggen

04/02/2022 18:42:08
Quote Anchor link
Hartelijk dank voor alle suggesties, ik ben er mee aan de slag gegaan.
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
 
- Ariën  -
Beheerder

- Ariën -

04/02/2022 18:48:30
Quote Anchor link
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.
Gewijzigd op 04/02/2022 18:49:17 door - Ariën -
 
Ad Fundum

Ad Fundum

04/02/2022 19:38:57
Quote Anchor link
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


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

Dick VanBruggen

04/02/2022 22:37:50
Quote Anchor link
- 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.





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.



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?
 
- Ariën  -
Beheerder

- Ariën -

04/02/2022 22:44:25
Quote Anchor link
Ja, het is een bestaande file.
 
Dick VanBruggen

Dick VanBruggen

04/02/2022 23:23:00
Quote Anchor link
Ad Fundum op 04/02/2022 19:38:57:
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


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:
Ad Fundum op 04/02/2022 19:38:57:
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


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.
 
Ad Fundum

Ad Fundum

05/02/2022 19:00:20
Quote Anchor link
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!
 
Dick VanBruggen

Dick VanBruggen

06/02/2022 19:43:56
Quote Anchor link
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!


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?
 
Ivo P

Ivo P

07/02/2022 09:02:12
Quote Anchor link
Onderdrukken van de foutmeldingen lijkt soms zinvol. Zeker als het resultaat toch is wat je wilde hebben.

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.
 
Ad Fundum

Ad Fundum

07/02/2022 11:16:33
Quote Anchor link
Was het maar alleen '0000-00-00', dan ging het nog wel.
MySQL kan ook 'gewoon' ongeldige data opslaan, zoals '2022-02-29'.
 
Ivo P

Ivo P

07/02/2022 14:31:52
Quote Anchor link
Dat is gewoon de februari-telling van Ronflonflon (Jacques Plafond) toch?
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.