In der Regel bedeutet das du wirklich mit DB-Queries die SW5 DB prüfen musst. Ist das dann wirklich soweit korregiert (was ich jetzt nicht beurteilen kann) dann mal bei der Migration die Prüfsummen löschen und noch mal alles migrieren. Die Migration selber aber NICHT abschließen.
Ich hatte deshalb gefragt, weil sich im Laufe der Zeit manchmal vieles ändert. Diese Änderungen können später bei der Migration Probleme bereiten.
Das habe ich in der Tat gemacht.
dann mal bei der Migration die Prüfsummen löschen und noch mal alles migrieren.
Wenn ich die Prüfsummen lösche, habe ich bereits vorhandene Produkte doppelt in der DB. Oder?
Nein, das passiert nur wenn die Migartion abgeschlossen wird. Sollte man aber auf keinem Fall machen. Das Löschen der Prüfsummen dient nur dazu, dass alle Daten noch einmal neu erfasst und überrüft werden. Mit dem anlegen einer Prüfsumme wird nur verhindert, dass bereits migrierte Daten nicht noch mal geprüft werden.
Das Löschen der Prüfsumme macht auch Sinn, wenn sich nachträglich in SW5 doch noch viele Daten verändert haben.
Aber was auch komisch ist, dass überhaupt kein Kunde und keine Bestellung importiert wurde. Es können ja nicht alle Daten fehlerhaft gewesen sein.
Also wenn alle Kunden und Bestellungen fehlen muss noch ein globales Problem vorliegen (so mir bisher nicht bekannt). Nun, die Migration unterliegt einer gewissen Reihenfolge. Erst Kunden, dann Bestellungen. Heißt also, es muss geprüft werden warum die Kunden nicht migriert werden. Hierzu müsste es im Log vielleicht noch Anhaltspunkte geben. Die können ja nicht alle wegen der Standard-Zahlungsart blockieren. So ein Fall wäre mir neu.
Danke erst mal für Deinen Beistand und Hilfe.
Ich lasse das nachher nochmals durchlaufen.
Eigentlich sind die Fehlermeldungen bis auf die Anzahl recht überschaubar:
ein paar Info:
[info] SWAG_MIGRATION__SHOPWARE_UNSUPPORTED_NUMBER_RANGE_TYPE
Unsupported number range type
NumberRange-Entity with source id "930" could not be converted because of unsupported type: invoice_diff.
zig. tausende Errors, alle von einem der drei „Typen“:
[error] SWAG_MIGRATION_RUN_EXCEPTION
An exception occurred
Entity: customer, sourceId: 0197f9dc36ce729c8538f126077d35c4
An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1364 Field 'default_payment_method_id' doesn't have a default value
…
[error] SWAG_MIGRATION_RUN_EXCEPTION
An exception occurred
Entity: order, sourceId: 0197f9dd644b71c8834b47ba7ede08c0
An exception occurred while executing a query: SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`db`.`order_customer`, CONSTRAINT `fk.order_customer.customer_id` FOREIGN KEY (`customer_id`) REFERENCES `customer` (`id`) ON DELETE SET NULL ON UPDATE CASCADE)
…
[error] SWAG_MIGRATION_RUN_EXCEPTION
An exception occurred
Entity: order_document, sourceId: 0197f9e14f977331b5a32bd184368d86
An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1364 Field 'file_type' doesn't have a default value
…
Ganz normale Infos, weil es einfach nur die angelegten Typen (Nummernkreise) in SW6 so nicht gibt. Kommt bei allen Migrationen als Info.
Ein noch etwas seltsamer Fehler, der bei meinen Migrationen (über ein duzend) so nicht vorgekommen ist. Hier würde ich mittles der UUID 0197f9dc36ce729c8538f126077d35c4 noch mal versuchen an die Kundennummer zu kommen. Damit dann mal im SW5 den Kunden aufrufen und seine Einstellungen prüfen.
Vielleicht mal zum Test dann bei diesem Kunden im SW5 einfach nur auf speichern klicken. Dann bei der Migration die Prüfsummen löschen und Kunden/Bestellungen neu durchlaufen lassen. Dann prüfen ob der Kunde übernommen wurde.
Hintergrund dieser Idee: Ich hatte mal eine Migration wo es einfach nicht die Produkte übernommen hatte. Es wurde angezeigt dass Stock und Preis fehlten, was jedoch völliger Unsinn war. Nachdem ich dann zum Test bei einzelnen Produkten einfach nur auf speichern geklicht hatte (also ohne Änderung) klappte dann die Migration. Soll heißen, in SW5 gab es irgendwelche inkorrekten Datensätze die optisch im Backend NICHT sichtbar waren.
Das sind praktisch Folgefehler. Bedeutet, die Bestellung konnte nicht angelegt werden, weil der dazugehörige Kunde noch nicht existiert. Diese Fehler gehen automatisch weg, wenn der Kunde dazu abgelegt wurde.
Liegt auch vielelicht einfach nur daran, dass dieser Dokumenttyp in SW6 nicht gibt. Muss jetzt aber nicht unbedingt Probleme bereiten. Sobald das Import der Kunden klappt, und die Bestellungen drin sind, kann man dann prüfen ob das Dokument an sich so übernommen wurde.
Mal so Grundsätzliches bei Kunden
Du müsstest im SW5 Shop folgendes überprüfen:
Ja, ist manchmal scheiß viel Arbeit, aber andere Möglichkeiten gibt es ja nicht.
Ich selber habe diese Version noch gar nicht benutzt, liegt daran das meine ganzen Migrationen noch unter SW 6.6 vollzogen wurden. Es könnte sein, dass die neue Version sensibler geworden ist.
Mal so zum Testen in SW5:
SELECT su.customernumber, su.paymentID
FROM s_user su
LEFT JOIN s_core_paymentmeans tmp ON ( tmp.id = su.paymentID )
WHERE tmp.id is NULL
Es zeigt alle Kunden an, wo die eingestellte Zahlungsart gar nicht mehr existiert. Vielleicht bringt das etwas irgenwie weiter.
Vielleicht mal zum Test dann bei diesem Kunden im SW5 einfach nur auf speichern klicken. Dann bei der Migration die Prüfsummen löschen und Kunden/Bestellungen neu durchlaufen lassen. Dann prüfen ob der Kunde übernommen wurde.
Es betrifft ja wirklich alle Kunden …
Du müsstest im SW5 Shop folgendes überprüfen:
Ich habe das alles mal geprüft und es sieht gut aus. Zudem habe ich noch die Liefer- und Rechnungsadressen geprüft.
Aber das? Wo denn noch?
s_user, s_user_addresses, s_user_billingaddress, s_user_shippingaddress, s_order_billingaddress, s_order_shippingaddress … was jetzt nur die globalen Userdaten betrifft
Bei der Zuordnung der Zahlungsarten müsste es bei dir etwa so aussehen:
Ich frage mal ganz blöd: aber auf welche Shopware Version möchtest du migrieren? Eine „default payment method id“ gibt es bei Shopware 6.7 für Kunden überhaupt nicht mehr. Kann es sein, dass evtl. die Migration hier nicht richtig funktioniert?
Viele Grüße
Auf 6.7 ja. In der Tabelle customer gibt es aber ein Feld default_payment_method_id.
Also so als Feedback kann ich nur sagen/schreiben, dass es unter SW 6.6 mit dem Migrations-Tool Version 14.1.0 solchen Fehler bezüglich default_payment_method_id nicht begeben hatte. Daher oben schon meine Vermutung wegen der neuen Version. Auch das Migrations-Tool kann fehlerhaft sein, alles in der Verganheit leider schon gehabt.
Ich habe jetzt mal ein Test mit SW 6.7 und dem Migration-Tool 15.0.2 gemacht. Dort wurde mir der Fehler bezüglich „default_payment_method_id“ nicht angezeigt.
und ich hatte schon Hoffnungen …
Nur mal so aus Neugier: Welche Version hat denn der SW5 Shop? Ich hatte jetzt mit 5.7.11 getestet und alle Kunden wurden übernommen.
5.7.18
Aber vielleicht sind das bei mir alles irgendwelche Folgefehler von irgendetwas …
Kannst Du mal bitte schauen, ob Du in der Tabelle customer ein Feld default_payment_method_id hast?
Laut 6.7 changelog:
Customer: Default payment method removed
- Removed default payment method from customer entity, since it was mostly overriden by old saved contexts
- Logic is now more consistent to always be the last used payment method
Viele Grüße
