Update 5.1.4 ging ohne Probleme bei mir. Mehrfach :)
Jetzt habe ich gerade mit HeidiSQl in meine “Live” geguckt, welche 5.1.3 sind. Hier hat “mapping_id” auch schon einen index. Irgendwo müssen die ja nun schon hergekommen sein! Die Wege von diesem Shop und dem Testshop haben sich ja vor 5.0.0-RC getrennt. Und auch im zweiten Shop - der aus 4.3.6 hochgeupdatet wurde, ist dieser index in 5.1.3 schon vorhanden.
Hallo,
ich kann natürlich nicht ausschließen, dass ein Plugin den Index gesetzt hat.
Zumindest kann ich in einer 4.3.6, 5.0.1 und 5.1.2 keinen Index in der Datenbank finden. Es gibt auch keine Migration die diesen Index setzt, außer die aktuelle 633.
Die Lösung für dein Problem wäre ja aktuell, den Index zu entfernen und ihn nochmal durch das Update setzen zu lassen.
Moritz
So werde ich das mit den Live-Shops machen.
Dennoch eine spannende Frage. Ausser Piwik habe ich keine weiteren „externen“ Plugins installiert - nur was bei Shopware schon dabei ist.
Da fällt mir nur noch All-Inkl. als Quelle ein, aber warum sollten die bei einen Serverumzug ausgerechnet diesen einen index setzen?
Jetzt muss ich aber erstmal den zweiten Testshop reanimieren 
[Edit]
In den Tiefen vom Webspace habe ich noch eine Testinstallation rumliegen, die eine SW 5.0.0 mit Demodaten ist. Und rate mal: Auch hier ist der index bereits gesetzt *Schulter zuck* - an mir liegt es nicht, wenn es an SW auch nicht liegt, kann es ja nur noch irgendwie am Hoster liegen, der bei einen Umzug etc. selber den Index setzt. Na hoffentlich werden hier nicht noch andere „All-Inkl“-Kunden beim Update auf 5.1.4 Probleme bekommen. Ich habe 5 Datenbanken - und in allen Datenbanken ist der Index schon vor dem Update gesetzt!
[Edit2]
Was SQL betrifft, bin ich derzeit etwas raus. Aber kann man bei ALTER TABLE nicht auch eine condition einbauen? Dann wäre es bei solchen Änderungen egal, ob sich vorher schon ein index eingeschlichen hat, oder nicht.
Wie gesagt hatte ich keine Probleme und bin ja auch bei All-Inkl.
Da ich die Testshop immer aktuell halte war das Update von 5.1.3 auf die 5.1.4 und theoretisch waren das mal 4.3 Shops die upgedatet wurden.
@sonic , wie sehe ich denn ob der index schon in der Alten Datenbank gesetzt ist? über phpMyAdmin sehe ich das doch nicht.
Habe genau das gleiche in meinem Test-System, super blöd. Was nun?
Update war von 5.1.3 auf 5.1.4, ich bin da immer aktuell.
Per phpMyAdmin oder vergleichbares Tool den Index löschen und Update neu aufrufen. Wenn noch die Fehlerseite im Browser ist, einfach reload.
1 „Gefällt mir“
Perfekt, Danke für den Tipp. Stimmt, der Index war schon gesetzt. Sehr merkwürdig.
Hat jedenfalls wunderbar geholfen, den Index manuell vorher zu löschen.
Vielen Dank!
All-Inkl.?
Es geht hier nicht um doppelte Einträge in der Tabelle, sondern darum, ob vor dem Update schon ein Index auf mapping_id gesetzt ist. Siehe oben Screenshot von phpMyAdmin.
Ich hab mal Version 3 von KAS aus geöffnet: Shop ist 5.1.3 - mit Index…
Also ich habe die Zeile aus dem Bild " mapping_id" gelöscht und dann lief das update nach dem reload der Seite durch., Danke
1 „Gefällt mir“
Ich hatte gerade auch das Problem mit dem Index in der Tabelle s_article_img_mapping_rules Der Shop ist auch bei all-inkl gehostet! Nachdem ich den Index gelöscht habe, lief das Update fehlerfrei durch.
Mit diesem Hoster hatte ich bis jetzt immer nur Ärger 
Gruß
Marco
Hallo zusammen
Wir hatten dasselbe Problem, der oben beschriebene Ratschlag hat auch bei uns funktioniert. Ebenfalls all inkl…
Danke und Grüsse
Andy
Zu All-Inkl.:
Ich hatte letztens ein Gespräch mit einen Techniker. Wenn ein Script auffällt, weil es wegen fehlender Indizes in der Datenbank den Server unnötigt belastet, setzen die so einen Index selber (was i.d.R. Eingenbasteleien betrifft)! Eigentlich sollte der Kunde dann per E-Mail informiert werden. Offensichtlich werden Shopware-Datenbanken vermehrt “geändert”, ohne dass es eine Info-Mail gibt. Da Mensch nun nicht weiss, ob noch weitere Tabellen / Tabellenspalten davon betroffen sind, sollte Shopware darüber nachdenken, ob man das Updatescript nicht soweit anpassen kann, das entweder solche Fehler übergangen werden, oder vorher eine Abfrage kommt, ob ein Index nicht doch schon gesetzt wurde.
Bin auch bei all-inkl…musste auch wie oben beschrieben, die letzte der aufgeklappten Zeilen löschen damit das update durchgeführt wurde.
Danke euch für die Lösung !
Vielen Dank für die Infos hier im Forum. Hatte gerade die gleichen Probleme beim Update auf 5.1.5. (all-inkl) und konnte sie dank eurer Hilfe schnell lösen.
Hier mal eine Reaktion von All-Inkl:
Hallo Herr xxx,
wir entschuldigen uns hiermit das wir Sie über diese Änderung nicht informiert haben.
Wir haben diesen Index aus unseren Optimierungen entfernt um weitere Problem zu vermeiden.
Allerdings sollte hier auch Shopware nachbessern, da der Index auch durch Sie oder andere Optimierungstools gesetzt hätte werden können und dies kein Grund für einen Abbruch des Updates sorgen sollte.
Leider ist Shopware immer wieder auffällig, wenn eine bestimmte Anzahl an Artikel überschritten werden. Die Änderungen wurden vorgenommen um die best mögliche Verfügbarkeit und Geschwindigkeit zu gewährleisten.
Da bin ich dann auch mal ganz auf der Seite von All-Inkl. - solche Fehler könnte man wirklich im Updater abfangen.
Und aus einer zweiten E-Mail - ich hoffe, SW nimmt das dann auch an:
Wir werden uns in den nächsten Tagen Shopware in Verbindung setzen, von unserer Seite steht einer Zusammenarbeit an Optimierungen nichts im Wege.
Sorry für die späte Antwort - ja, das Problem trat unter all-inkl auf.
Hi - ich habe es wohl falsch gemacht:
Habe die „mapping_id“ aus s_article_img_mapping_rules gelöscht und auch keine Indizis mehr. Leider funzt das Update nach wie vor nicht. Ich hätte wohl die Indizes
löschen sollen anstatt die Mapping ID. Wie kann ich es nun dennoch fixen damit ich das Update durchführen kann?
Besten Dank im voraus!