Hallo! Ich versuche mich derzeit an dem Update von 3.5.7 auf 4.1.3 Habe den Shop auf eine Testumgebung kopiert, die config und die Datenbankeinträge angepasst und dann den Cache gelöscht und kann dann in der Testumgebung den Shop auch problemlos bedienen. Habe dann das Update gestartet und bekomme als Warnung eigentlich nur das memory_limit angezeigt, dass auf der Testumgebung nur 64M beträgt. Leider bleibt beim dann durchgeührten Update das Datenbank-Update hängen (der blaue Balken steht beim rechten Ende des „p“ vom Wort „update“. Habe das Update dann irgendwann (nachdem es einfach nicht mehr weiterging) abgebrochen und das Datenbank Backup wieder eingespielt und dann versucht, die SQL-Statements einzeln über den Import in phpMyAdmin einzuspielen. Hier bricht das Update aber schon beim ersten (0-start.sql) nach kurzer Zeit mit folgender Fehlermeldung ab: Fehler SQL-Befehl: CREATE TABLE IF NOT EXISTS `new_s_articles_attributes` ( `id` int(11) NOT NULL AUTO\_INCREMENT, `articleID` int(11) unsigned DEFAULT NULL, `articledetailsID` int(11) unsigned DEFAULT NULL, `attr1` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT '0', `attr2` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT '0', `attr3` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT '0', `attr4` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT NULL, `attr5` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT NULL, `attr6` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT NULL, `attr7` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT NULL, `attr8` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT '0', `attr9` mediumtext COLLATE utf8\_unicode\_ci, `attr10` mediumtext COLLATE utf8\_unicode\_ci, `attr11` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT NULL, `attr12` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT NULL, `attr13` varchar(255) COLLATE utf8\_unicode\_ci DEFAULT '0', `attr14` varchar(255) COLLATE utf8\_unico[...] MySQL meldet: Dokumentation #1005 - Can't create table 'shop\_in.new\_s\_articles\_attributes' (errno: 150) Hat irgendjemand eine Idee, woran es liegen könnte und wie ich das Problem lösen kann? Ich möchte wirklich gerne auf Version 4 wechseln, leider läuft aber das Update nicht durch. Vielen Dank, Gerti
[quote] Tabelle kann nicht angelegt werden. Wenn die Fehlermeldung auf errno 150 verweist, schlug die Tabellenerzeugung fehl, weil ein Fremdschlüssel-Constraint nicht richtig gebildet wurde. [/quote] Sehr merkwürdig… Machst du denn ein Update -direkt- auf 4.1.3 oder über Umwege bzw über 4.0 und 4.1.? Viele Grüße
Hallo, das ist ein Foreign Key Constraint und liegt wahrscheinlich daran, dass nicht alle TAbellen InnoDB als Storage Engine verwenden. Ich hänge mal einen Ausschnitt von einem alten Post von mir an, ich vermute mal, es hat sich nicht viel in den Deltas diesbezüglich geändert: Die Reihenfolge der Tabellen-Migrationen in start0.sql sollte das Problem lösen. ALternativ kann man die Tabellen auch ohne ForeignKeys migrieren, muss die dann aber nacher von Hand setzen. Viele Grüße und Erfolg H. Thomas (info@mycetome.de) start0.sql. Die new_s_articles_attributes “referenziert” die s_articles_details . Die wird aber erst später umgestellt und ist dann sicher InnoDB. Wenn die alte Version kein Innodb verwendet, dürfte es der Grund für den Fehler sein. Dann muss man die Reihenfolge der Backups/Umbenennung der Tabellen einfach ändern und die Tabellen auf die “referenziert” wird, vorab umstellen. Alternativ die alten Versionen auf InnoDB umstellen. s_articles ist zu dem Zeitpunkt der Fehlermeldung ja bereits neu und macht daher keine Probleme bei den Foreign Keys. .
Hi! Das Update mache ich direkt von der 3.5.7 auf die 4.1.3 Wenn ich die Reihenfolge der Statements ändere, komme ich über einige Fehler beim manuellen Import hinweg, nachdem ich aber vier oder fünf Fehler so beseitigen konnte, hängt es anderer Stelle mit folgendem Fehler, auch wenn ich imho die Reihenfolge bereits geändert habe: SQL-Befehl: DROP TABLE IF EXISTS `s_core_countries_states` ; MySQL meldet: Dokumentation #1217 - Cannot delete or update a parent row: a foreign key constraint fails Gruß, Gerti
Ähm funktioniert das denn direkt von der 3.5.7 auf die 4er? Ich glaube nicht! Ich habe sogar von der 4.0.6 auf die neueste alle zwischenschritte einzeln gemacht
Hi! Ist auf die 4.1.2 (nicht 4.1.3, war mein Fehler) und dafür gibt es einen Updater. Die SQL Statements habe ich nun eingelesen bekommen, indem ich SET FOREIGN_KEY_CHECKS = 0 an den Anfang der Statements geschrieben habe. Nach dem Update bin ich jetzt wohl irgendwie im Wartungsmodus: Unsere Website befindet sich gerade in der Wartung. Gruß, Gerti
[quote=„Gerti“]Hi! Ist auf die 4.1.2 (nicht 4.1.3, war mein Fehler) und dafür gibt es einen Updater. Die SQL Statements habe ich nun eingelesen bekommen, indem ich SET FOREIGN_KEY_CHECKS = 0 an den Anfang der Statements geschrieben habe. Nach dem Update bin ich jetzt wohl irgendwie im Wartungsmodus: Unsere Website befindet sich gerade in der Wartung. Gruß, Gerti[/quote] Schau im normalen Update-Prozedere für 4 nach. Das ist normal, damit das Update durchlaufen kann. http://wiki.shopware.de/Minor-Update-4. … 5_454.html Mit der Methode sind jetzt aber alle Foreign-Key-Constraints ignoriert worden und die dienen ja eigentlich zur Konsistenz der Daten. Ich schätze die Gefahr hier zwar nicht so groß ein, aber besser wäre es, die einzelnen Fehler zu isolieren und zu beseitigen. Das Auftreten der Probleme deutet eigentlich schon auf eien nicht standardgemäße Datenbank im 3.5er hin. Viele Grüße H. Thomas
Hi! Ich hatte in der Vergangenheit schon mehrfach ein Update von der 3.5.7 auf eine 4.0.x in meiner Testumgebung gemacht und die liefen immer durch. Die Foreign Key Checks habe ich am Ende ja wieder aktiviert, so dass es hoffentlich kein Problem geben sollte. Ich habe halt keine Idee, wie ich die Fehler anders beseitigen soll… Gruß, Gerti
Hi! Habe gerade nochmal das Update von 3.5.7 auf 4.0.4 versucht und das läuft fehlerfrei durch. Also muss es wohl doch irgendwie mit dem Updatescript und nicht mit meiner Datenbank zusammenhängen?! Gruß, Gerti
[quote=“Gerti”]Hi! Habe gerade nochmal das Update von 3.5.7 auf 4.0.4 versucht und das läuft fehlerfrei durch. Also muss es wohl doch irgendwie mit dem Updatescript und nicht mit meiner Datenbank zusammenhängen?! Gruß, Gerti[/quote] Hallo Gerti, woher hast du das Update-Script auf 4.0.4? Ich habe leider auch das Problem das er beim MySQL-Update bei ca. 50% einfach “einfriert” und nichts mehr passiert… hatte erst vermutet das die php-execute time nicht reicht, aber das hat sich als falsch erwiesen, es scheint wirklich am Script iwo zu liegen bzw. an der Reihenfolge der MySQL-Dumps… lg, André
Hi! Das hatte ich vor längerer Zeit mal heruntergeladen. Ich könnte es Dir zur Verfügung stellen, wenn Du Interesse hast. Eigentlich wäre ich aber eher daran interessiert, dass der Fehler im Updatescript irgendwie behoben wird, denn es scheint ja wirklich etwas nicht zu stimmen, wenn ich nicht der einzige mit diesem Problem bin. Vor allem habe ich nur wenige Artikel im Shop und auch sonst nur sehr wenige Änderungen am Template, etc. vorgenommen. Gruß, Gerti
[quote=„Gerti“]Hi! Das hatte ich vor längerer Zeit mal heruntergeladen. Ich könnte es Dir zur Verfügung stellen, wenn Du Interesse hast. Eigentlich wäre ich aber eher daran interessiert, dass der Fehler im Updatescript irgendwie behoben wird, denn es scheint ja wirklich etwas nicht zu stimmen, wenn ich nicht der einzige mit diesem Problem bin. Vor allem habe ich nur wenige Artikel im Shop und auch sonst nur sehr wenige Änderungen am Template, etc. vorgenommen. Gruß, Gerti[/quote] Hi Gerti, ja das Problem hab ich bei einem Kunden, nachdem ich gestern 5x seinen Shop geschossen habe und wieder herstellen musste, ist mir dann um 23 Uhr auch die Lust vergangen. Der Kunde hat fast einen Standardshop ohne groß Plugins und keine Änderungen an Templates (nur CSS)… Bei mir ist ebenfalls das Problem SQL-Befehl: DROP TABLE IF EXISTS `s_core_countries_states` ; MySQL meldet: Dokumentation #1217 - Cannot delete or update a parent row: a foreign key constraint fails das die Dumps nicht durchlaufen - ich finde es seltsam das dieses Updatescript nicht wirklich passt, denn die Installation ist wirklich Standard. Vielleicht kann sich einer von Shopware dazu mal melden - ich habe gestern versucht manuell die Deltas durchzujagen, endete jedoch damit das ich in den ersten 4-5 sql-Dumps fehler hatte, die man zwar unterdrücken konnte, aber das letztlich nur in einem riesen Desaster endete. Alles in allem, hab ich seine Shopware Version 3 nun erstmal PHP 5.4 angepasst, damit er überhaupt wieder Artikel bearbeiten/anlegen kann. Wenn Shopware 3 schon nicht mehr geupdatet wird für solche Dinge, sollte zumindest das Updatescript sauber durchlaufen. Greetz
Hallo Ich hab genau das selber Problem Ich hab Shopware 3.5.6 und möchte updaten auf shopware 4 Ich bräuchte nur die Kunden da es ja mit Export und Import nicht möglich ist muss ich es Updaten. Ich bräuchte es so schnell wie möglich. Ich hatte das schon durch aber das geht leiter nicht http://wiki.shopware.de/Shopware-Update … 5_454.html kann jemand weiterhelfen? gruß dema