Ich hab schon an verschiedenen Stellen in der DB 0000-00-00 00:00:00 als Datumsangabe gesehen, etwa für last_modified in manufacturers. Das war bisher kein Problem, aber jetzt bin ich am einrichten von Vario, und da scheitert der Import mit der Meldung Wenn man das Datum googelt, findet man schnell sowas: https://www.php.de/forum/webentwicklung/php-einsteiger/95229-erledigt-datum-30-11-0001 Leuchtet ein, statt ein nuller-Datum sollte das Feld doch leer, also NULL sein. Ist das eine Fehlkonfig. meiner DB, oder Gambio-Standard? Kann ich die betroffenen Felder auf NULL setzen? Sollte ich das generell über alle Felder der ganzen DB hinweg, oder ist Gambio auf die Angabe 0000-00-00 00:00:00 angewiesen?
Das genaue Verhalten hängt davon ab, welche MySQL-Version man hat und wie die jeweilige Tabelle definiert ist. Man kann DATETIME-Spalten so definieren, dass sie auch NULL akzeptieren; muss man aber nicht. Ältere MySQL-Versionen haben 0000-00-00 als Wert für DATETIME-Spalten akzeptiert, aktuelle werfen damit einen Fehler. Deswegen haben wir eigentlich schon vor längerem auf 1000-01-01 als „Nulldatum“ umgestellt.
Ok, das heisst dann? Kann ich die DB auf STRICT umstellen? MySql ist 5.7.26, GX3.9.3.1 Beim Beispiel Hersteller sehe ich, das ist ein timestamp, kein datetime. Erscheint unlogisch, wenn date-added ein datetime ist... Code: +---------------------+-------------+------+-----+-------------------+-----------------------------+ | Field | Type | Null | Key | Default | Extra | +---------------------+-------------+------+-----+-------------------+-----------------------------+ | manufacturers_id | int(11) | NO | PRI | NULL | auto_increment | | manufacturers_name | varchar(64) | NO | MUL | | | | manufacturers_image | varchar(64) | YES | | NULL | | | date_added | datetime | YES | | NULL | | | last_modified | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | +---------------------+-------------+------+-----+-------------------+-----------------------------+
Bei dieser Tabellenstruktur wird last_modified von MySQL selbst aktualisiert (on update CURRENT_TIMESTAMP), deswegen ist die Spalte etwas speziell. In dieser Spalte dürftest du auch kein '0000-00-00' sehen, denn: Bei date_added ist es vorstellbar, dass dir irgendein DB-Frontend den NULL-Wert als '0000-00-00' darstellt; das wäre aber falsch. Der kleinste mögliche Wert ist hier '1000-01-01 00:00:00'. Wie dem auch sei, Vario macht da irgendwas falsch und kommt beim Jonglieren mit Nulldaten durcheinander.
Nein, ich glaube vario macht nichts falsch... Das steht ja schon in der DB und vario stolpert drüber. Was ja korrekt ist, da wie du sagst das nicht da stehen dürfte, oder? Hmm, logisch wäre ja, wenn statt Nullen der created-Wert drin wäre. @Marco (Gambio) , siehst du ein Problem, wenn ich das per SQL überall von 000... auf gleich setze? @barbara , was steht denn bei dir in modified-spalten von noch nie geänderten Produkten? Die gibts ja auch bei zb. products. Und wohl noch anderem.
in products_last_modified steht teilweise auch eine 0000.00.00 00:00:00, Bei den Herstellern habe ich überall ein Datum.
Ist das bei den Herstellern teils das gleiche wie das created? oder hast du die einfach alle schon bearbeitet?
Erstellungs-Datum ist entweder ein altes Datum, 000.00.00, oder NULL Das Datum der Bearbeitung ist bis zur Uhrzeit bei fast allen identisch - da vermute ich eine Übertragung von einem WaWi-Test
Ich würde vermuten, dass da nicht viel kaputt(er) gehen kann, wenn du das händisch reparierst. Erst recht nicht, wenn du ein Backup in der Hinterhand hast.