Hallo Allerseits, bei den vielen updates auf neue Shopwareversionen, wird empfohlen eine DB-Sicherung zu machen. Die updates haben mehr oder weniger auch immer problemlos funktioniert. Jetzt habe ich probeweise versucht eine DB-Sicherung wieder in phpMyAdmin einzuspielen. Dies scheiterte immer am setzen der Triggerrechte in den s_user… Tabellen. Die Datenbank liegt bei Domainfactory und dort hat man erst ab einem 100.-€/Monat-Tarif Zugriff auf die Triggerrechte der DB. Welche Erfahrung habt ihr mit dem einspielen der Sicherungen gemacht, gibt es evtl. ein Workaround? Schöne Grüße Richard
Ich nutze zur Sicherung von Datenbanken immer eine kostenlose Software. Mit MySQLDumper können Sicherungskopien erstellt und bei Bedarf auch wieder hergestellt werden. Das ganze funktioniert sehr einfach und hat bei mir immer funktioniert. mysqldumper Viel Erfolg Harald
1 „Gefällt mir“
[quote=„Richard_III“]Hallo Allerseits, bei den vielen updates auf neue Shopwareversionen, wird empfohlen eine DB-Sicherung zu machen. Die updates haben mehr oder weniger auch immer problemlos funktioniert. Jetzt habe ich probeweise versucht eine DB-Sicherung wieder in phpMyAdmin einzuspielen. Dies scheiterte immer am setzen der Triggerrechte in den s_user… Tabellen. Die Datenbank liegt bei Domainfactory und dort hat man erst ab einem 100.-€/Monat-Tarif Zugriff auf die Triggerrechte der DB. Welche Erfahrung habt ihr mit dem einspielen der Sicherungen gemacht, gibt es evtl. ein Workaround? Schöne Grüße Richard[/quote] Hallo, das sollte bei domainfactory eigentlich auch so funktionieren. Was genau ist denn gemacht worden und wo wird Trigger genau benötigt? Ich nehme an, es ist ein managed hosting-Paket, oder? MySQL-Dumper ist bei einem vernünftig dimensioniertem MySQL-Angebot eigentlich überflüssig. Zumindest sollte man aber darauf achten, dass man eine verschlüsselte Verbindung mit MySQL-Dumper oder vergleichbaren Tools wie HeidiSQL aufbaut. Das geht leider nicht immer, aber ist mit phpmyadmin meist problemlos möglich.
Vielen Dank für die Antworten 220 Tabellen werden prolemlos eingespielt, bis zu denen, die einen Trigger benötigen CREATE TABLE `s_user_billingaddress` ( `id` int(11) NOT NULL AUTO\_INCREMENT, etc... etc... etc... PRIMARY KEY (`id`), UNIQUE KEY `userID` (`userID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8\_unicode\_ci AUTO\_INCREMENT=27 ; -- -- Trigger `s_user_billingaddress` -- DROP TRIGGER IF EXISTS `dbxx`.`Update_Billingaddress_Attributes_On_User_Billingaddress`; DELIMITER // CREATE TRIGGER `dbxx1`.`Update_Billingaddress_Attributes_On_User_Billingaddress` AFTER UPDATE ON `dbxx`.`s_user_billingaddress` FOR EACH ROW BEGIN UPDATE s\_user\_billingaddress\_attributes ba SET ba.lastmodified = now() WHERE ba.billingID = NEW.id; END // DELIMITER ; Der Domainfactory-Support kann mir leider auch nicht helfen: [quote]Einen Dump mit den Inhalten „CREATE TRIGGER…“ einzuspielen ist wie vermutet aufgrund der fehlenden Rechte nicht in Ihrem aktuellen Tarif möglich.[/quote]
Hallo, ich habe mehrere Datenbank-Dumps von shopware (4.1.4 und 4.1.4) gehostet bei df angesehen und es kommt kein Trigger vor. Auch nicht bei den s_user_billingaddress. Ich kann jetzt natürlich nicht ausschließen, dass einzelne Plugins dies erfordern. Allerdings frage ich mich, wie ein Trigger jemals eingerichtet worden sein soll, wenn die notwendigen Rechte auf dem SQL-Server nicht zur Verfügung stehen. Ist das SQL-File von der Datenbank bei df erzeugt worden?
Hallo hth, die Datenbank habe ich nach Shopware-Anleitung in phpMyAdmin auf dem df-Server exportiert. es sind mehrere create Trigger enthalten: CREATE TRIGGER `dbtest`.`Update_Billingaddress_Attributes_On_User` AFTER UPDATE ON `dbtest`.`s_user` CREATE TRIGGER `dbtest`.`Update_Billingaddress_Attributes_On_User_Billingaddress` AFTER UPDATE ON `dbtest`.`s_user_billingaddress` CREATE TRIGGER `dbtest`.`Update_Shippingaddress_Attributes_On_User_Shippingaddress` AFTER UPDATE ON `dbtest`.`s_user_shippingaddress` Beim manuellen einfügen der SQL-befehle bekomme ich bei folgenden ebenfalls Probleme: -- Constraints der Tabelle `s_articles_attributes` -- ALTER TABLE `s_articles_attributes` ADD CONSTRAINT `s_articles_attributes_ibfk_1` FOREIGN KEY (`articleID`) REFERENCES `s_articles` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION, Exportiere ich den falsch? Die Frage ist berechtigt [quote]Allerdings frage ich mich, wie ein Trigger jemals eingerichtet worden sein soll, wenn die notwendigen Rechte auf dem SQL-Server nicht zur Verfügung stehen.[/quote]
Hallo, ob das falsch exportiert wird, kann ich ohne meine Glaskugel schlecht sagen. Allerdings wüsste ich jetzt auch nicht, wie man bei dem df-phpmyadmin die Trigger beim Export unabsichtlich einfügen könnte. Ist das eine Standard CE-Installation, welche Plugins sind aktiv (waren vielleicht mal aktiv)? Die Constraints (ALter Table) werden eigentlich am Ende des SQL-Dumps gesetzt und das kopierte Fragment sieht auf den ersten Blick in Ordnung aus. Das kann natürlich nur funktionieren, wenn vorab die ganzen Tabellen korrekt gesetzt und befüllt sind. Eigentlich wird für jede Tabelle zuerst das Create-Statemnent zur Erzeugung der Tabellenstruktur ausgeführt und anschließend die TAbelle mit Inhalt gefüllt. Create Trigger taucht dann nicht auf. Am Ende des SQL-Files kommen dann die Constraints mit Alter Table. Dafür müssen aber alle Create und Befüllungs-Statements durchgelaufen sein, sonst gibt es dort Probleme. Wie sieht das denn aus: 1. in phpmyadmin die Datenbank auswählen (alle Tabellen sind zu sehen, eine je Zeile). 2. Oben auf den Reiter exportieren klicken. 3. Dann “Senden an” auswählen und die Datei auf dem eigenen Rechner abspeichern. Sind in dieser Datei dann Create Trigger enthalten (Angabe der Plugins nicht vergessen)? EDIT OK, habe gerade den WIKI EIntrag mal angesehen. Das ist eigentlich das obige Vorgehen. Beim Importieren würde ich vorab aber alle alten Tabellen in der Datenbank löschen und nicht nur leeren oder aktualisieren. Das ist problemloser, nützt allerdings bei dem Create Trigger Problem nichts.
Hallo hth hier sind die Plugins: http://imgur.com/2udztCC hier nochmal die Struktur der Tabelle “s_user” http://imgur.com/OEWiTwU
[quote=„Richard_III“]Hallo hth hier sind die Plugins: http://imgur.com/2udztCC[/quote] Das sieht doch nach einer Standardinstallation aus. Das Update-Plugin haben wir noch nie benutzt, daher weiß ich nicht, ob dieses an der Tabelle den Trigger setzt. Wüsste aber auch nicht, warum es dies tun sollte. Eigentlich halte ich das für ausgeschlossen. [quote=„Richard_III“] hier nochmal die Struktur der Tabelle „s_user“ http://imgur.com/OEWiTwU[/quote] Keine Ahnung, wie dort ein Trigger auftauchen kann. Ich habe es gerade bei zwei df gehosteten Shops kontrolliert, um Hosting spezifische Faktoren auszuschließen, er ist dort nicht vorhanden. Bleibt immer noch die Frage, wie der überhaupt gesetzt werden konnte, wenn die Rechte nicht vorhanden sind und „wer“ dies getan hat? Bzgl. des Update-Plugins als Verursacher, müsste Shopware etwas sagen können. Den Trigger zu entfernen, erscheint mir zwar harmlos, andererseits dürfte er ja nicht ohne Grund in dieser Installation vorhanden sein. Das Entfernen wäre auch nur eine Beseitigung des Symptoms, ohne die Ursache zu kennen. Ich würde allerdings beim df-Support ein Online-Ticket asbetzen und fragen, wie der Trigger gesetzt werden konnte, wenn die Rechte nicht ausreichend sind. Im Endeffekt muss der Trigger gelöscht werden, damit die Backups jemals wieder eingespielt werden können. Natürlich könnte man einfach das Create TRIGGER Statement im SQL-Dump entfernen und anschließend das File in eine leere Datenbank importieren - Tabellen vorher löschen und dann wieder in die Datenbank importieren. Das ist wahrscheinlich der einfachste Weg in diesem Fall. Allerdings würde ich eine neue Shopwareinstallation parallel in einer Subdomain erstellen und das Vorgehen dort ausprobieren.
Hallo hth, vielen Dank für Deine ausführliche Antwort. Habe jetzt noch eine Anfrage an df gestellt, werde weiter berichten. Hier ist der prompte Kommentar vom df-Support: [quote]Wie es genau zu der Konstellation kommen konnte, ist anhand der vorliegenden Logfiles nicht ersichtlich. Sie können testweise “Update_Billingaddress_Attributes_On_User” via phpMyAdmin zu entfernen und einen erneuten Dump erstellen. Danach können Sie überprüfen ob ein Import mit dem erneuten Dump möglich ist, ob ab hier Fehler entstehen. Gerne können Sie uns auch mitteilen, wie genau Sie den Dump einspielen möchten und wir können dies für Sie auch einmal testen. Beachten Sie bitte, dass die Ziel-Datenbank hierbei leer sein muss, damit wir einen Dump importieren können.[/quote] Gruß Richard