Testspace erstellen - Fehler bei SQL Import

Nope, ich brauchs wenn dann für MAC. Der mysqldumper wird direkt am Server installiert, richtig? Muss mich da mal in die Thematik “Erweiterungen installieren” einlesen.

gibts tatsächlich auch für mac, habe ich gerade gesehen
https://dev.mysql.com/downloads/workbench/

https://sequelpro.com/download für OS X wäre auch schick.

Habe mir Workbench heruntergeladen und installiert. Zugriff auf die Original DB funktioniert auch reibungslos. Ebenso der Export der Tables (ohne Views).

Beim Import in die neue DB Fehlermeldung:

ERROR 1045 (28000): Access denied for user ‘dbwpfh_3’@‘ip.ip.ip.ip’ (using password: NO)

Ich habe hier 3 verschiedene User zur Verfügung:

einen Allgemeinen (?)
einen R/W
einen R/O

Import läuft mit keinem der drei. Egal ob nur Daten oder Daten & Struktur.

Liegt es vielleicht wirklich auch an den Rechten der Benutzer?

Es steht doch alles da?!?!?!?!

die meisten Hoster, die ich kenne, erstellen immer gleichnamige Datenbank + Benutzer, so dass man für eine andere Datenbank auch entsprechend einen anderen Benutzer nehmen muss.
Ist es hier vielleicht auch der Fall? Welcher Hoster ist das überhaupt?

Wie genau? Wenn man sich in phpmyadmin bei “Tabellen” befindet und dann auf den Reiter “Export” klickt werden views auch mit exportiert.

Access denied heisst für mich dass der User nicht ausreichend Rechte hat, um Daten in diese DB zu schreiben. Mehr Rechte kann ich jedoch nicht mehr vergeben.

Falls ich etwas übersehen haben sollte bitte um Info - danke!

Benutzer ist ein anderer als bei der Original DB, richtig. Auf das wurde geachtet. Hoster ist Hetzner.

@leofonic: Eventuell liegt hier der Fehler.

Schritt für Schritt mit MySQL Workbench

  1. DB Verbindung herstellen
  2. Menüpunkt “Management” wählen
  3. DB auswählen
  4. “Select Tables” wählen (Tabellen mit Präfix oxv_ werden abgewählt)
  5. Data Dump only wählen
  6. Export to Self-Contained File wählen
  7. Start Export

=> dann erhalte ich - klarerweise - ein einziges .sql File. Beim Importversuch dann Fehlermeldung siehe oben.

@patchwork.de Danke, soweit reicht mein Englisch auch noch :slight_smile: Verbindung auf die DB geht ja - wird vorher getestet.

… Zugriff verweigert → wahrscheinlich Benutzername / Passwort falsch …

Wie wärs mal hiermit? https://www.google.de/search?q=mysql+grundlagen

Access denied heisst für mich dass der User nicht ausreichend Rechte hat, um Daten in diese DB zu schreiben. Mehr Rechte kann ich jedoch nicht mehr vergeben.

Falls ich etwas übersehen haben sollte bitte um Info - danke!

Benutzer ist ein anderer als bei der Original DB, richtig. Auf das wurde geachtet. Hoster ist Hetzner.

@leofonic: Eventuell liegt hier der Fehler.

Schritt für Schritt mit MySQL Workbench

DB Verbindung herstellen
Menüpunkt “Management” wählen
DB auswählen
“Select Tables” wählen (Tabellen mit Präfix oxv_ werden abgewählt)
Data Dump only wählen
Export to Self-Contained File wählen
Start Export

=> dann erhalte ich - klarerweise - ein einziges .sql File. Beim Importversuch dann Fehlermeldung siehe oben.

@patchwork.de Danke, soweit reicht mein Englisch auch noch :slight_smile: Verbindung auf die DB geht ja - wird vorher getestet.

Wie schon mehrfach von unterschiedlichen Leuten geschrieben bedeutet dies, dass sich der Benutzer an der Datenbank nicht anmelden kann, da vermutlich die Zugangsdaten nicht stimmen.

Wie gesagt, die Verbindung wird ja vorher getestet und da funktioniert alles… daher verstehe ich das nicht…

Um nochmal auf das ursprüngliche Problem zurückzukommen.

Das “DEFINER=shop_web1@%” bedeutet, daß die View im Kontext des users shop_web1 ausgeführt werden soll. Dazu werden Super-Privilegien (root) benötigt. Nur root kann Objekte unter einem anderen User als sich selbst anlegen. Außerdem muss der User shop_web1 auf dem Zielsystem existieren.

Am einfachsten wäre es, den Teil “DEFINER=shop_web1@%” aus der SQL-Datei zu entfernen (Search & Replace). Wenn die Angabe des DEFINERs fehlt, wird die view im Kontext des ausführenden Users angelegt. Das passt normalerweise im OXID, da im Normalfall sowieso alle Objekte unter einem einzigen User angelegt werden.

Die Ursache ist, daß mysqldump immer automatisch den DEFINER reinschreibt.

Zum Nachlesen:
https://dev.mysql.com/doc/refman/5.7/en/stored-programs-security.html

Ich habe mir jetzt einen aktuellen Dump gezogen und nach “DEFINER…” gesucht. Nicht gefunden. Suche eingeschränkt auf “shop_web1” - gefunden. Schaut allerdings so aus:

DEFINER=shop_web1@%

Ganze Zeile sieht so aus:
DROP TABLE IF EXISTS oxv_ddmenu;

CREATE ALGORITHM=UNDEFINED DEFINER=shop_web1@% SQL SECURITY INVOKER VIEW oxv_ddmenu AS select ddmenu.OXID AS OXID,ddmenu.OXSHOPID AS OXSHOPID,ddmenu.DDNAME AS DDNAME,ddmenu.DDNAME_1 AS DDNAME_1,ddmenu.DDNAME_2 AS DDNAME_2,ddmenu.DDNAME_3 AS DDNAME_3,ddmenu.DDACTIVE AS DDACTIVE,ddmenu.DDSORT AS DDSORT,ddmenu.DDTYPE AS DDTYPE,ddmenu.DDCONTENTTYPE AS DDCONTENTTYPE,ddmenu.DDCATEGORYID AS DDCATEGORYID,ddmenu.DDCATEGORYLVL AS DDCATEGORYLVL,ddmenu.DDCONTENTCATEGORYID AS DDCONTENTCATEGORYID,ddmenu.DDCONTENTACTIVE AS DDCONTENTACTIVE,ddmenu.DDLINK AS DDLINK,ddmenu.DDLINK_1 AS DDLINK_1,ddmenu.DDLINK_2 AS DDLINK_2,ddmenu.DDLINK_3 AS DDLINK_3,ddmenu.DDLINKTARGET AS DDLINKTARGET,ddmenu.DDWIDGETS AS DDWIDGETS,ddmenu.DDWIDGETS_1 AS DDWIDGETS_1,ddmenu.DDWIDGETS_2 AS DDWIDGETS_2,ddmenu.DDWIDGETS_3 AS DDWIDGETS_3,ddmenu.OXTIMESTAMP AS OXTIMESTAMP,ddmenu.OXSHOPINCL AS OXSHOPINCL,ddmenu.OXSHOPEXCL AS OXSHOPEXCL,ddmenu.OXMAPID AS OXMAPID from ddmenu ;

Nochmals meine Frage: Wie muss ich diese Zeile bearbeiten, damit ich den Dump wieder in eine DB zurückspielen kann?

=> Wenn ich nur einen Export der Tables mache werden anscheinend auch noch Views mit exportiert, ich sehe aber keine Möglichkeit diese komplett auszuschließen. Und so ein super SQL Spezi bin ich nicht, wie man sicherlich merkt.

  1. mach mal MySQL Workbench auf
  2. Lege eine neue Verbindung für die Live-DB an
  3. lege eine neue Verbindung für die Test-DB an.
  4. verbinde dich mit der live DB
  5. Klick auf “Data Export” in der linken Sidebar.
  6. dann im neu aufgegangenen “object Selection” Fenster die DB auswählen und rechts auf “unselect all” und dann auf “select tables” klicken.
  7. direkt drunter bei “Export Options” die Checkbox “Export to Self-Contained File” anklicken
  8. Pfad merken und auf “start export” unten rechts klicken
  9. ein Getränk deiner Wahl holen/zubereiten gehen.
  10. wenn es fertig ist, neue Verbindung zu der Test-DB herstellen
  11. links auf “Data Import / Restore” klicken
  12. “Import from Self-Contained File” auswählen und die eben exportierte Datei finden
  13. bei “Default Target Schema” die neue Datenbank ausählen
  14. unten rechts auf “Start import” klicken.

Dann im Admin Views neu generieren und das wäre es schon.

Nimm einfach das “DEFINER=shop_web1@%” raus, so daß das Statement dem Muster

CREATE OR REPLACE SQL SECURITY INVOKER VIEW oxv_ddmenu AS SELECT ....

entspricht.

views sollten erst gar nicht in einem Export enthalten sein wie schon mehrfach von verschiedenen Helfern in diesem Beitrag geschrieben

Aber es wurde auch noch keine Lösung gepostet, wie man den Export von views unterbinden kann. Ich finde die Option weder in myphpadmin, noch im SQL Workbench. Wenn es da einen Trick gibt, bin für jede Hilfe dankbar.

Werde mich mal an die Anleitung von @vanilla_thunder halten, obwohl das eigentlich der Vorgehensweise entspricht, wie ich gearbeitet habe.

Alle Programme bieten die Möglichkeit auch einzelne Tabellen zu exportieren - zB phpmyadmin: