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

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.

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

[size=xsmall]Toevoeging op 04/02/2022 22:40:45:[/size]

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

Ja, het is een bestaande file.

Ad Fundum op 04/02/2022 19:38:57

[quote="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.
[/quote]

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.

[size=xsmall]Toevoeging op 05/02/2022 00:16:00:[/size]

- Ariën - op 04/02/2022 22:44:25

Ja, het is een bestaande file.

En waar vind ik die? Je houdt het spannend :)

[size=xsmall]Toevoeging op 05/02/2022 17:34:26:[/size]

Dick VanBruggen op 04/02/2022 23:23:00

[quote="Ad Fundum op 04/02/2022 19:38:57"]
[quote="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.
[/quote]

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.

[size=xsmall]Toevoeging op 05/02/2022 00:16:00:[/size]

- Ariën - op 04/02/2022 22:44:25

Ja, het is een bestaande file.

En waar vind ik die? Je houdt het spannend :)
[/quote]

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.

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!

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?

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.

Was het maar alleen '0000-00-00', dan ging het nog wel.
MySQL kan ook 'gewoon' ongeldige data opslaan, zoals '2022-02-29'.

Dat is gewoon de februari-telling van Ronflonflon (Jacques Plafond) toch?