Update von SW5.2.22 auf SW5.5.10: Datenbank korrupt - Was tun?

Hallo,

ich möchte gerne von SW5.2.22 auf SW5.5.10 updaten.

Meinen erster Update Versuch vor 2 Tagen habe ich wieder rückgängig gemacht, indem ich mein Dateibackup eingespielt habe, aber NICHT mein Datenbankbackup.

Jetzt habe ich zwei Tage lang den SW5.2.22 Shop mit der SW5.5.10 Datenbankstruktur betrieben , wobei auch ein paar Bestellungen eingegangen sind. Sonst wurde nichts geändert.

Habt Ihr eine Idee, wie ich jetzt am besten upgraden kann?
 

Ich sehe 2 Möglichkeiten:

  1. Ich nehme mein Backup von vor 2 Tagen und kopiere aus der Datenbank alle s_order* Tabelleneinträge aus der aktuellen Datenbank, die seitdem dazu gekommen sind. Dabei kann allerdings einiges schiefgehen

  2. Ich versuche ein Update zu SW5.5.10 ohne die Datenbank upzudaten. Allerdings ist mir nicht klar, wie ich die Datenbankupdates vermeiden kann. Ich habe bereits versucht, im Verzeichnis “update-assets/migrations” die SQL Updates zu löschen, aber es scheint sehr schwer zu sein, alle Datenbankupdates aufzuspüren.

Welche Methode empfehlt Ihr mir, die sicher und einfach ist?

Danke

Jens

Ist das Datenbank-Update denn damals einwandfrei durchgelaufen? 

Weil dann kannst du das Update einfach nochmal machen.

Das Datenbank Update ist damals problemlos durchgelaufen. 

Ich habe jetzt versucht die update…zip Datei zu entpacken und habe danach das Update in der Linux Commandline durchgeführt. Dann erhalte ich Fehlermeldungen, dass manche Tabellen wie basket_signatures bereits existieren.

Funktioniert das Update im Browser besser?

Danke und viele Grüße 

Jens

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍

Ich habe versucht, das Datenbankupdate im Browser nochmal durchzuführen, aber ich erhalte immer noch Fehlermeldungen, dass die Tabelle „s_orders_basket_signatures“ bereits existiert. Dann wird das Datenbankupdate abgebrochen.

Ich habe auch versucht die neuen Bestellungen zu meiner alten Datenbank per import/export Plugin hinzuzufügen, aber es gibt einen Fehler ohne Logfile Eintrag. Also funktioniert auch das nicht.

 

Also habe ich jetzt eine korrupte Datenbank und kann nicht mehr updaten.

 

Hat jemand eine Idee, wie ich hier weiterkomme?

 

Vielen Dank

Jens

Tabelle löschen und nochmal das Update anstoßen.

Das Import/Export Modul unterstützt keinen Import von Bestellungen, daher klappt das auch nicht.

1 Like

Danke für die Antwort.

Wenn ich die order_basket_signatures Tabelle lösche kommt gleich die nächste “duplicate index” Fehlermeldung von einem anderen Datenbank Update Kommando. Hierbei kann ich nichtmal erkennen von welchem Sql Kommando diese Fehlermeldung stammt, sonst könnte ich es in den update-assets/migrations händisch löschen.

Oder ich versuche aus update-assets/migrations alle sql updates herauszuschmeissen. Wenn ich in diesem Verzeichnis nach “$sql” suche, müsste ich alle Dateien finden, in denen die Tabelle geändert wird.

Frage an @Moritz_Naczenski:

Werden im migrations Verzeichnis die Dateien nach ihrer Nummerierung abgearbeitet? Die signatures Änderung wird in Datei 907 oder so durchgeführt. Das würde bedeuten, dass ich nur die folgenden Nummern ansehen muss.

@Moritz Naczenski schrieb:

Tabelle löschen und nochmal das Update anstoßen.

Das Import/Export Modul unterstützt keinen Import von Bestellungen, daher klappt das auch nicht.

Ja, die werden in der Reihenfolge abgearbeitet. Musst halt alle migrations durchschauen 

1 Like

@Moritz Naczenski schrieb:

Ja, die werden in der Reihenfolge abgearbeitet. Musst halt alle migrations durchschauen 

Danke dann kommt wenigstens keine Langeweile auf :slight_smile:

Viele Grüsse und danke für die schnellen Tipps!

Jens 

OK, ich habe es geschafft:

Ich habe folgende Dateien im “update-assets/migrations” Verzeichnis geändert:

907: IF NOT EXISTS 
917: remove insert into custom sorting table
923: IF NOT EXISTS 
925: IF NOT EXISTS 
934: IF NOT EXISTS 
938: ADD IF NOT EXISTS 
946: IF NOT EXISTS 
1415: VERY COMPLEX CHANGES “IF NOT EXISTS” and removed lines
1433: ADD COLUMN IF NOT EXISTS 
1437: IF NOT EXISTS 
1447: IF NOT EXISTS 

Also mein Ratschlag:
Nach einem Test Update im Live Shop IMMER wieder das DB Backup einspielen, wenn man wieder zur alten Version zurückgeht.

Irgendwie logisch :slight_smile: