Hallo, ich habe nun schon mit dem zweiten Kunden, welcher SW3.5 im Einsatz hat große Probleme bei Update auf 4. Gibt es Probleme, wenn ich die SW3.5 DB kopiere und in einer Testumgebung wieder zum Laufen bringe. Das SQL Update läuft dann nicht durch. Fehler über Fehler. U.A. Das Datenbank-Update konnte nicht abgeschlossen werden. Ein Fehler beim Import der Datei " deltas/0-start.sql" ist aufgetreten. [HY000] Can’t create table ‘d01800ef.new_s_articles_attributes’ (errno: 150) Das ist ein Foreign Key Problem. Wie kann ich so was zukünftig lösen. Ist recht nervig. Hat jemand eine Idee? Danke
Hallo, Ablauf bzgl. Import der DB lokale Installation (Xampp oder Uwampp): - php.ini die max_execution_time auf 30 Minuten setzen damit es komplett durchlaufen kann - Jetzt ein Update nach dem anderen einspielen Sollte das nicht funktionieren, bei mir hat es ab der Version 4.0.8 auf die 4.1 nicht geklappt, dann bleibt dir nur eine Neuinstallation über. (Sprich aus dem alten Shop alles exportieren was nur geht und nach der Neuinstallation alles importieren)
Hallo, welche StorageEngine verwenden denn die alten 3.5er? Am einfachsten ist es wahrscheinlich, die ForeignKeys der betroffenen Tabellen vor dem Update zu entfernen. Die theoretische Gefahr, dass die Integrität des Datenbestandes dann nicht mehr gewährleistet ist, muss man wohl in Kauf nehmen. Auf der anderen Seite scheint die ja auch nicht mehr gegeben zu sein. Man kann natürlich auch in der 3.5er Datenbank die ForeignKeys neu aufbauen lassen und dann die Migration versuchen. Edit: Mir ist da gerade eingefallen, dass ich im Frühjahr schon einen Beitrag dazu geschrieben habe. Dort war es die Storage Enginge. Ich habe gerade einen Blick in die Deltas geworfen 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. Ist nicht getestet. Viele Grüße H. Thomas Viele Grüße [quote=„ottscho“]Hallo, ich habe nun schon mit dem zweiten Kunden, welcher SW3.5 im Einsatz hat große Probleme bei Update auf 4. Gibt es Probleme, wenn ich die SW3.5 DB kopiere und in einer Testumgebung wieder zum Laufen bringe. Das SQL Update läuft dann nicht durch. Fehler über Fehler. U.A. Das Datenbank-Update konnte nicht abgeschlossen werden. Ein Fehler beim Import der Datei " deltas/0-start.sql" ist aufgetreten. [HY000] Can’t create table ‚d01800ef.new_s_articles_attributes‘ (errno: 150) Das ist ein Foreign Key Problem. Wie kann ich so was zukünftig lösen. Ist recht nervig. Hat jemand eine Idee? Danke[/quote]
Hi, Danke für die AWs. Wenn ich die DB lokal importiere, so klappt das update. Bei dem letzte Kunden habe ich dies so gemacht und die DB dann wieder hochgespielt. Jetzt habe ich aber eine DB, welche im gezippten Zustand schon 55MB hat. Diese nach dem Update dann wieder einspielen geht schief. Eine SSH Console steht icht zur Verfügung. Allgemein nervt es ziemlich. Wenn ich über PHPMYADMIN die DB direkt kopiere 1zu1 verstehe ich nicht, warum dies dann nicht funktioniert. Wie lösche ich die Forein Keys? Das Update ist von 3.5.6 auf 4.0.4 (bzw. das Betra Script direkt auf 4.1.2). >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. Richtig. Das ist der Fall. (Ist ja eig. ein Fehler des Scripts). Habe ich auch schon probiert. Leider zieht sich dies zielich durch, so dass ich erst Update für Update anschauen muss. Ich habe auch schon versucht alel Tabellen umzustellen: SELECT CONCAT(‘ALTER TABLE ',table_schema,'.', table_name,' engine=InnoDB;’) FROM information_schema.tables WHERE engine = ‘MyISAM’ AND table_schema = ‘shopware_db’; Das klappt so leider nicht. D.h. ist muss wohl Update für Update einsipelen und bei Fehlern immer die Referenz beachten.
Hallo, ich finde nur 36 Stellen in 3 files mit constraint als Suchbegriff. Das sollte sich doch leicht in den Griff bekommen lassen. Ich finde es zumindest bei der Tabellenanzahl vollkommen im Rahmen eines DB-UPdates zwischen Major-Versionen. Klar: ein Klick ist es nicht mehr und man kann schon darüber diskutieren, ob dies am Anfang mit den s_article Tabellen nicht geändert werden könnte. Auf der anderen Seite werden die Autoren von einer Standard-Shopware-Installation ausgegangen sein, nehme ich an. Alle Tabellen auf einen Streich nach InnoDB zu konvertieren, ist nicht unbedingt eine gute Idee. Man kann da auch etwas kaputt machen. Ich würde mich schon von Fehler zu Fehler hangeln. Bleibt die Frage, warum die alten Datenbanken so aussehen und man nicht noch mehr Überaschungen erlebt. Lange Rede kurzer Sinn: Fix jede Stelle einzeln! @Datebankgröße: Nimm ein anderes Tool, HeidiSQL etc. , dann kann man doch den ganzen Update-Prozeß bequem local durchführen und anschließend auch große Datenbanken importieren. Ohne SSH sind die SKriptlimits auch bestimmt mies und werden Probleme bei dem Update erzeugen. Aber was ist das für ein Hosting-Paket, ss gibt ssh-Zugang doch schon für rund 10 Euro pro Monat? SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE engine <> ‚InnoDB‘ könnte gehen. Aber da kann man bestimmt nicht drauf zugreifen. Sollte der concat nicht so aussehen? SELECT CONCAT('ALTER TABLE ‚, table_name, ’ ENGINE=InnoDB;‘) Eigentlich ist es aber keine schlechte Idee, eine Kopie zu machen und dort den Engine zu ändern, wie Shopware es tut. Keine Überprüfung der referential constraints: SET FOREIGN_KEY_CHECKS = 0; Sinn der Sache ist das aber nicht!
Hi Thomas, vielen Dank für deine Hilfe. Hat alles geklappt 
[quote=„ottscho“]Hi Thomas, vielen Dank für deine Hilfe. Hat alles geklappt :)[/quote] Wie denn jetzt genau? Ich könnte da auch noch einen Erfahrungsbericht für die Migration von 3.5 mit Varianten gebrauchen. Funktioniert das problemlos? Es stand auch noch eine Frage bzgl. Löschen den ForeignKeys aus: 1. Man kann die Tabelle einfach ohne ForeignKey Constraints kopieren und die anschließend per ALter Table neu setzen. CREATE TABLE table_name_new LIKE table_name_old; INSERT INTO table_name_new SELECT * table_name_old; Anschließend muss man die constraints alle per Hand setzen. 2. Auch Handarbeit, weil man die fk_symbol alle suchen muss oder eben suchen lässt und die Liste dann übernimmt. ALTER table_name DROP FOREIGN KEY fk_symbol Viele Grüße Holger Thomas (info@mycetome.de)
Ich hatte in den Updates 0 und 1 die Reihenfolge der betroffenen Tabellen geändert. So das der Vorang zuerst gemacht wurde, bevor die Tabelle erstellt wird. Evtl. sollte dies Shopware im Script bedenken. Hatte dies nun schon 2 Mal. Ich denke es liegt daran, da diese Installationen schon ziemlich alt sind. Sprich von SW 3.0.x mitgezogen wurde… Danke dir.