Service
Daten massenhaft korrigieren, zuerst auf einer Testkopie
Ein massenhafter Datenfehler wird in einem Durchgang korrigiert, auf einer Testkopie erprobt, bevor es den Live-Shop trifft.
ProBezahlte Version
Was es ersetzt: 2–4 Std. Vorbereiten, Testen und Ausführen einer Datenbankkorrektur
auf Staging: zähl die Produkte mit Gewicht 0, für die es ein Gewicht in der Referenztabelle des Lieferanten gibt, zeig 10 Beispiele und bereite dann das Update vor. Nachdem ich Staging geprüft habe, mach dasselbe in der Produktivumgebung
Was der Chat tut
- Der Chat zählt und zeigt die betroffenen Produkte.
- Er zeigt die geplante Änderung und wie viele Produkte sie betrifft.
- Er behält die alten Werte, damit sich die Änderung rückgängig machen lässt.
- Er läuft zuerst auf der Testkopie, dann nach einer neuen Freigabe im Live-Shop.
Das Problem
Ein Import hat das Gewicht von 1.200 Produkten auf 0 gesetzt, also stimmen die Versandkosten nicht. Im Backend lässt sich das nicht massenhaft korrigieren.
Was Sie bekommen
Die Produktgewichte sind in einem Durchgang korrigiert, getestet vor der Produktivumgebung.
Sie behalten die Kontrolle
Sie sehen jede Änderung, bevor sie gespeichert wird, und nichts passiert ohne Ihr Ja. Diese tiefe Reparatur funktioniert nur, solange der Schalter Service an ist (er schaltet sich nach 3 Stunden selbst aus), und bewahrt eine Kopie jeder geänderten Datei und jedes geänderten Datensatzes auf.
Ähnliche Anwendungsfälle
Für Entwickler
- Bereich
- 5 · Service
- In TellMyShop Free
- nein, nur in der bezahlten Version
- Für
- Entwickler, Agentur / Freelancer
- Werkzeuge
- ps_db_query, ps_db_execute, ps_revert_change, ps_clear_cache
Schritt für Schritt
- Zählt die betroffenen Zeilen und zieht Stichproben mit ps_db_query auf der Staging-Kopie.
- Bereitet ein UPDATE nur der Tabelle product vor, ohne JOIN, damit die Zeilensicherung greift (die Werte kommen aus der Tabelle des Lieferanten, z. B. über eine Unterabfrage in SET), und zeigt die Vorschau von ps_db_execute: Zahl der Zeilen und Stichprobe.
- Läuft in einer Transaktion mit max_rows (bis zu 1000 pro Aufruf, die 1.200 Produkte gehen also in zwei Paketen nach ID-Bereich); die alten Werte jeder Zeile werden für ps_revert_change aufbewahrt.
- Sie prüfen Staging; dann dasselbe in der Produktivumgebung mit neuer Vorschau und Freigabe.
- Eine direkte Änderung an der Datenbank umgeht Modul-Hooks und Caches, deshalb schlägt der Chat vor, den Cache zu leeren und die Versandkosten im Warenkorb erneut zu prüfen.
Sicherheit
Service-Arbeiten (Dateien, Datenbank, Einstellungen) laufen nur, solange der Schalter Service an ist; er schaltet sich nach 3 Stunden selbst aus, und der Inhaber bekommt eine E-Mail, wenn er eingeschaltet wird. ps_db_execute führt ein INSERT/UPDATE/DELETE/REPLACE in einer Transaktion aus; die Vorschau zeigt die Zahl der Zeilen und eine Stichprobe, und die Änderung wird zurückgerollt, wenn sich mehr Zeilen als max_rows (bis zu 1000) ändern würden. Ein UPDATE oder DELETE auf einer einzigen Tabelle ohne JOIN behält eine Kopie jeder geänderten Zeile, sodass ps_revert_change es rückgängig machen kann. UPDATE/DELETE ohne WHERE braucht all_rows=true; ALTER/CREATE/DROP/TRUNCATE brauchen allow_ddl=true und lassen sich nicht rückgängig machen. Eine direkte Datenbankänderung umgeht Modul-Hooks und Caches, deshalb wird stattdessen ein reguläres Werkzeug genutzt, wann immer es eines gibt.
Zuletzt aktualisiert: 2026-10-25