Weiß ich nicht, Barbara, ich habe es nicht gemacht. Aber ich habe mir die Lösung zurecht gepopelt: Um die Kunden aus der Gruppe zu löschen nehme man PHP: DELETE FROM `address_book` WHERE EXISTS (SELECT `customers_id` FROM `customers` WHERE (`customers`.`customers_id`=`address_book`.`customers_id`) AND (`customers`.`customers_status`='16'));DELETE FROM `customers_info` WHERE EXISTS (SELECT `customers_id` FROM `customers` WHERE (`customers`.`customers_id`=`customers_info`.`customers_info_id`) AND (`customers`.`customers_status`='16'));DELETE FROM `customers` WHERE `customers_status` = '16'; Und dann kann man schön die Kundengruppe löschen und gut ist. Haken war, dass die Tabelle anscheinend umbenannt wurde. Aber dank MiniSQL kann man das sogar bequem im Shop nachschauen. Ich bin begeistert!
Hallo Petra, Wenn die alte DB in den neuen Shop geladen wurde, kann es noch mehr Probleme geben. Da würde ich eventuell ein Update-Paket erstellen (oder vom Update-Assistenten erstellen lassen) und nur den Ordner (gambio_updater" in den Shop laden und ausführen. Das bringt die DB auf den Stand des Shops.
Ich weiß es nicht, wie es gemacht wurde. Aber das es Kai gemacht hat, wird das schon richtig gewesen sein.
Doch, das geht im Insert wunderbar und ist meiner Meinung nach das Eleganteste, da es am besten zu lesen ist, da Spalte und Wert beieinander stehen.
Nun, das angeführt Script hat die Daten wohl gelöscht, aber dennoch nicht sauber. Ob es letztlich irgend welche Auswirkungen im Gambio Webshop hat, mag ich nicht zu beurteilen, aber Fakt ist, dass nur mit dem SQL-Script zumindest in folgenden Tabellen verwaiste Datensätze übrig bleiben: customers_basket; `customers_logs_history`, `customers_ip`, `customers_memo`, `customers_status_history`, `customers_wishlist`, `customers_wishlist_attributes` und eventuell auch noch anderen Tabellen (hab nicht alle durchsucht). Also alle Tabellen, wo der gelöschte Primärschlüssel customers_id als "Fremdschlüssel" vorkommt. Dort fehlt nun eine "Beziehung" zur Tabelle customers. Siehe dazu auch: https://de.wikibooks.org/wiki/Einf%C3%BChrung_in_SQL:_Fremdschl%C3%BCssel-Beziehungen Wie gesagt, ob es irgend eine Auswirkung auf die DB hat, weiß ich nicht, aber wenn man schon beinhart Daten mit Primärschlüsseln löscht, sollte man auch wissen, wo diese als Fremdschlüsseln vorkommen und auch dort die betreffenden Datensätze löschen. So macht man es halt in anderen Applikationen. Tabelle orders ist insofern eine Ausnahme, da kommt zwar customers_id auch vor, aber einerseits haut es dir alle Umsatzstatistiken zusammen, wenn dort die Uralt-customers auch gelöscht werden andererseits ist dort neben der customers_id auch der Name des Kunden hineingeschrieben worden, also weiß man indirekt wiederum zu wem die verwaisten Datensätze in den nicht gesäuberten customer-Tabellen (siehe oben) gehören. Genug der DB-Theorie, Hauptsache, Dein Shop funktioniert, wie du es haben willst.
Wo keine Bestellungen und keine Umsätze, da haut es mir auch nichts zusammen. Es ging ja lediglich darum, nur die eingefügten Kunden zu bereinigen. Mehr ist da auch nicht drin, außer die Kundendaten.
Na, dann paßt ja alles! Aber warum in einer Datenbank Kunden sind, die sich allesamt nur angemeldet hätten und dann nichts gekauft haben sollen, ist mir nicht klar, vor allem wie dann die Kundendaten rein kommen.... Ich hoffe aber, dass ich Dir vermitteln konnte, warum man normal alle Datensätze mit Fremdschlüsseln löschen sollte, wenn man die zugehören Primärschlüssel löscht.
Beim besten Willen aber ich sehe keine "Fremdschlüssel" in der Gambio DB erstellten Schema. Gerade durch "foreign_keys" (Fremdschlüssel) und einem "constraint" Ansatz werden alle Einträge die in Verbindung mit dem Fremdschlüssel in Zusammenhang stehe auf Anhieb gelöscht. Man muss also nicht zuerst alle "Verknüpfungen" zusammen suchen und dann erst die Einträge löschen. Ich glaube du verwechselst da etwas.
Kann ich dir erklären. Durch magnalister wurden alle Amazon Bestellungen in den Shop geladen. Dort wurden sie als Gast mit Kundenkonto abgelegt. Ein normales Löschen der Gastkonten war also nicht möglich. Da die Bestellungen aber sowieso in unsere Wawi eingelesen werden, brauche ich diese toten Adressen nicht. Ich darf sie nicht anschreiben und kann mit denen nix anfangen. Durch einen Fehler von Mailbeez, oder durch meine Einrichtung, wurden mal alle Kunden mit ausgelieferten Amazon Bestellungen angeschrieben. Der erhobene Amazonfinger kam postwendend
Die Gambio DB hat keine Foreign_key definiert! Zumindest sehe ich keine, wenn ich sie in der Workbench öffne. Ich denke, es liegt daran, dass es eine MyISAM und keine InnoDB ist. Jedenfalls wird kein Datensatz aus einer anderen tbl gelöscht, wenn man einen Datensatz aus customers löscht, obwohl die gelöschte customers_id (PK) in anderen tbls als FK vorkommt. Daher meine Empfehlung auch die anderen tbls zu "säubern".
Petra, ich wollte Dich nicht belehren, sondern nur verhindern, dass durch das Löschen von "Hauptdatensätzen", in anderen Tabellen unzuordenbare Daten herumschwirren. Wenn andere Tabellen ohnehin keine Datensätez, die auf die Haupttabelle referenzieren, dass ist es ja OK.
Das kann sogar sehr gut möglich sein. Beispiel Gastkonten: Wenn ich ein Gastkonto lösche, lösche ich nicht automatisch die Bestellung. Und ich habe mal versucht, alle Kundendaten als Liste zu bekommen. Geht nicht, weil alleine Adresse und Lieferanschrift in zwei Tabellen waren.
tiger, alles gut. Ich habe das jetzt auch nicht als Belehrung aufgefasst. Außerdem lernt man ja nie aus, gelle
@All, ich möchte gerne für alle Artikel inkl. Artikeleigenschaften den Lagerbestand ändern. Gibt es hierfür einen SQL-Befehl?
@Denis J. Damit würdest du ja den Kunden den Newsletter aufzwingen, auch wenn er ihn nicht möchte. Wer Interesse an dem Newsletter hat wird sich schon eintragen, man kann den Newsletter ja irgendwie schmackhaft machen, mit Rabatt oder so
Wenn er doch möchte: Code: update customers set customers_newsletter = 1; Vorher bitte Sicherung der DB erstellen. Ungetestet.