Upgrade 4.8.20 ⇒ 4.9.12 - SQL-Error on Setup

[rethus]

Ich bekomme bei einem Upgrade von 4.8.20 auf 4.9.12 folgende Fehlermeldungen im /logs/setuplog.txt

Unable to execute SQL statement:
ALTER TABLE `con_system_prop` CHANGE `idsystemprop` `idsystemprop` INT(11) NOT NULL AUTO_INCREMENT
Mysql Error: ALTER TABLE causes auto_increment resequencing, resulting in duplicate entry '11' for key 'PRIMARY' (1062)

Unable to execute SQL statement:
INSERT INTO `con_system_prop` SET `type` = 'codemirror', `name` = 'activated', `value` = 'true'
Mysql Error: Duplicate entry '0' for key 'PRIMARY' (1062)

Unable to execute SQL statement:
INSERT INTO `con_system_prop` SET `type` = 'system', `name` = 'insite_editing_activated', `value` = 'true'
Mysql Error: Duplicate entry '0' for key 'PRIMARY' (1062)

Unable to execute SQL statement:
INSERT INTO `con_system_prop` SET `type` = 'backend', `name` = 'backend_label', `value` = ''
Mysql Error: Duplicate entry '0' for key 'PRIMARY' (1062)

Unable to execute SQL statement:
INSERT INTO `con_system_prop` SET `type` = 'debug', `name` = 'module_translation_message', `value` = 'true'
Mysql Error: Duplicate entry '0' for key 'PRIMARY' (1062)

Unable to execute SQL statement:
INSERT INTO `con_system_prop` SET `type` = 'debug', `name` = 'debug_for_plugins', `value` = 'true'
Mysql Error: Duplicate entry '0' for key 'PRIMARY' (1062)

Das erste Kommando schlägt schon mal fehl, weil es am ändern des Feldes in AUTO_INCREMENT scheitert. Hier müsste ermittelt werden, was die letzte verwendete idsystemprop in der Tabelle ist, eins hinzugezählt werden, und dies dann als autoincrement-Wert gesetzt werden, dann geht dieses SQL-Statement:

Code: Alles auswählen

ALTER TABLE `con_system_prop`
  CHANGE `idsystemprop` `idsystemprop` INT(11) NOT NULL AUTO_INCREMENT, auto_increment=[i]<hier idsystemprop + 1>[/i];

Ist die Tabelle erfolgreich auf autoincrement geändert, funktionieren auch die nachfolgenden SQL-INSERTs.
Bitte mal prüfen und ggf. in 4.9.13 aufnehmen, falls das Problem dort besteht.

[Oldperl]

Servus,

Ich bekomme bei einem Upgrade von 4.8.20 auf 4.9.12 folgende Fehlermeldungen im /logs/setuplog.txt

Unable to execute SQL statement:
ALTER TABLE `con_system_prop` CHANGE `idsystemprop` `idsystemprop` INT(11) NOT NULL AUTO_INCREMENT
Mysql Error: ALTER TABLE causes auto_increment resequencing, resulting in duplicate entry '11' for key 'PRIMARY' (1062)

Bitte mal prüfen und ggf. in 4.9.13 aufnehmen, falls das Problem dort besteht.

Da muss man nichts in oder an der 4.9.13 ändern. Hier besteht offensichtlich bereits ein Problem in der DB deiner 4.8.20. Laut deinem Log hast Du den Eintrag mit der ID 11 zweimal in der Tabelle. Diesen einfach auf eine freie ID ändern, die con_sequence entsprechend anpassen und das Upgrade nochmal laufen lassen.
Ich denke das Setup muss und kann nicht jeden nur denkbaren Fehler abfangen, dafür hat es ja ein setuperror.log und das error.log. Das Setup sollte von einer funktionierenden 4.8er Datenbank ausgehen und beim Upgrade nach Möglichkeit Unterschiede in DB-Versionen und Syntax prüfen und gegebenenfalls beheben können.

Gruß aus Franken

Ortwin

[rethus]

Danke Oldperl, Hab ich mir mal den DB-Dump genauer angesehen.

Die ID 11 ist ursprünglich nur einmal in der Tabelle vorhanden. Und die con_sequence steht bereits auf einen korrekten Wert (in meinem Fall 59)

Allerdings irritiert mich an dem DB-Dump, die INSERTS für ID 10 -38. Hast du ne Idee, warum er die 'frontendlogic-lastscantime' und 'frontendlogic-pluginorder' so oft drin hat. In einer anderen Installation hat er die nur jeweils ein mal drin.

Auch die ID 0 für einen der frontendlogic-lastscantime irritiert mich. Hier der hastebin: https://hastebin.com/gopuzapowo.sql

BTW: Das Problem das mysql dabei rumzickt eine bestehende Tabelle mit einem AUTO_INCREMENT zu belegen ist nicht neu. Kurz gegoogelt findest du massenweise Einträge dazu.
Denke es kann aus Sicht der problemlos(ser)en Installation nicht schaden, vor diesem ALTER-Statement die con_sequens nach der nächsten ID abzufragen, und diese wie oben von mir angegeben dem ALTER-Statement hinzufügen.

[Oldperl]

Servus,

Allerdings irritiert mich an dem DB-Dump, die INSERTS für ID 10 -38. Hast du ne Idee, warum er die 'frontendlogic-lastscantime' und 'frontendlogic-pluginorder' so oft drin hat. In einer anderen Installation hat er die nur jeweils ein mal drin.

Die sollten auch nur einmal vorkommen. Kann es sein, dass das System schon auf einem neuere DB-Server lief, so dass ältere SQL-Anweisungen nicht kompatibel waren. Ansonsten könnten es auch Restfragmente aus älteren Contenidos sein, eventuell gab es da mal einen entsprechenden Bug. Wenn man das unbedingt wissen will, könnte man ja die Timestamps mal vergleichen bzw. in ein Datum wandeln.

Auch die ID 0 für einen der frontendlogic-lastscantime irritiert mich.

Die gehört ja da auch nicht hin, und ist wohl auch dein Problem beim Upgrade, da das System versucht diesen 0-Eintrag zuzuordnen, und dabei natürlich auf den ersten bereits vorhandenen Eintrag in der "neuen" DB versucht (wohl deine ID 11).

BTW: Das Problem das mysql dabei rumzickt eine bestehende Tabelle mit einem AUTO_INCREMENT zu belegen ist nicht neu. Kurz gegoogelt findest du massenweise Einträge dazu.
Denke es kann aus Sicht der problemlos(ser)en Installation nicht schaden, vor diesem ALTER-Statement die con_sequens nach der nächsten ID abzufragen, und diese wie oben von mir angegeben dem ALTER-Statement hinzufügen.

Wie Du ja selbst siehst, anhand deines SQL-Dumps, sind viele der alten Contenido Datenbanken etwas "buggy" und man neigt dabei dazu, diese Karteileichen mitzuschleppen. Daher halte ich persönlich nichts davon, das ein Setup da dann alle möglichen, und auch unmöglichen, Bugs der DB erkennen und reparieren soll, zumal manche dieser Fehler erst bei genauerem Hinschauen als solche zu indentifizieren sind (siehe dein frontendlogic-lastscantime). Lasse mich da aber gerne von was Anderem überzeugen.

Gruß aus Franken

Ortwin

[frederic.schneider_4fb]

Ich sehe das eigentlich wie Ortwin. Bis zu einem gewissen Punkt müssen wir natürlich Fehler abfangen, wenn sie häufiger auftauchen etwa, oder durch Upgrades verursacht werden. In dem Fall würde ich mich aber schwer tun, für alle Eventualitäten Vorgänge zu implementieren. Ich bin da wie Ortwin zwar auch nicht felsenwert auf meiner Meinung festgelegt, aber zumindest ist das meine Tendenz.