MySQL-Fehler 1449: Der als Definierer angegebene Benutzer existiert nicht

Wenn ich die folgende Abfrage ausführe, erhalte ich einen Fehler:

SELECT `a`.`sl_id` AS `sl_id`, `a`.`quote_id` AS `quote_id`, `a`.`sl_date` AS `sl_date`, `a`.`sl_type` AS `sl_type`, `a`.`sl_status` AS `sl_status`, `b`.`client_id` AS `client_id`, `b`.`business` AS `business`, `b`.`affaire_type` AS `affaire_type`, `b`.`quotation_date` AS `quotation_date`, `b`.`total_sale_price_with_tax` AS `total_sale_price_with_tax`, `b`.`STATUS` AS `status`, `b`.`customer_name` AS `customer_name` FROM `tbl_supplier_list` `a` LEFT JOIN `view_quotes` `b` ON (`b`.`quote_id` = `a`.`quote_id`) LIMIT 0, 30 

Die Fehlermeldung lautet:

 #1449 - The user specified as a definer ('web2vi'@'%') does not exist 

Warum bekomme ich diesen Fehler? Wie repariere ich es?

Dies tritt häufig beim Exportieren von Sichten / Triggern / Prozeduren von einer database oder einem Server in eine andere auf, da der Benutzer, der dieses Objekt erstellt hat, nicht mehr existiert.

Sie haben zwei Möglichkeiten:

1. Ändern Sie den DEFINIERER

Dies ist möglicherweise am einfachsten, wenn Sie anfänglich Ihre databaseobjekte importieren, indem Sie alle DEFINER statementen aus dem DEFINER entfernen.

Den Definierer später zu ändern ist etwas komplizierter:

Wie ändere ich den Definierer für Ansichten?

  1. Führen Sie diese SQL aus, um die erforderlichen ALTER-statementen zu generieren

     SELECT CONCAT("ALTER DEFINER=`youruser`@`host` VIEW ", table_name, " AS ", view_definition, ";") FROM information_schema.views WHERE table_schema='your-database-name'; 
  2. Kopieren Sie die ALTER-statementen, und führen Sie sie aus

Wie ändere ich den Definer für gespeicherte Prozeduren?

Beispiel:

 UPDATE `mysql`.`proc` p SET definer = 'user@%' WHERE definer='root@%' 

Sei vorsichtig, denn dadurch werden alle Definierer für alle databaseen geändert.

2. Erstellen Sie den fehlenden Benutzer

Wenn Sie bei der Verwendung der MySQL-database folgenden Fehler gefunden haben:

 The user specified as a definer ('someuser'@'%') does not exist` 

Dann können Sie es lösen, indem Sie Folgendes verwenden:

 GRANT ALL ON *.* TO 'someuser'@'%' IDENTIFIED BY 'complex-password'; FLUSH PRIVILEGES; 

Von http://www.lynnnayko.com/2010/07/mysql-user-specified-as-defininer-root.html

Das funktionierte wie ein Zauber – Sie müssen nur einige someuser in den Namen des fehlenden Benutzers ändern. Auf einem lokalen Entwicklungsserver verwenden Sie normalerweise nur root .

Überlegen Sie auch, ob Sie dem Benutzer ALL Berechtigungen erteilen müssen oder ob er mit weniger auskommt.

Der Benutzer, der die SQL-Ansicht oder Prozedur ursprünglich erstellt hat, wurde gelöscht. Wenn Sie diesen Benutzer neu erstellen, sollte er Ihren Fehler beheben.

Wenn der Benutzer existiert, dann:

 mysql> flush privileges; 

Erstellen Sie den gelöschten Benutzer wie folgt:

 mysql> create user 'web2vi'; 

oder

 mysql> create user 'web2vi'@'%'; 

Lösung ist nur eine einzelne Zeile Abfrage wie folgt:

 grant all on *.* to 'ROOT'@'%' identified by 'PASSWORD' with grant option; 

Ersetzen Sie ROOT durch Ihren mysql-Benutzernamen. Ersetzen Sie PASSWORD mit Ihrem mysql Passwort.

Für zukünftige Googler: Ich habe eine ähnliche Nachricht erhalten, die versucht, eine Tabelle in einer database zu aktualisieren, die keine Ansichten enthält. Nach einigen Ausgrabungen stellte sich heraus, dass ich Auslöser für diese Tabelle importiert hatte, und das waren die Dinge, die von dem nicht existierenden Benutzer definiert wurden. Das Löschen der Trigger triggerse das Problem.

Folge diesen Schritten:

  1. Gehe zu PHPMyAdmin
  2. Wählen Sie Ihre database
  3. Wähle deine Tabelle aus
  4. Im oberen Menü auf ‘Auslöser’ klicken
  5. Klicken Sie auf “Bearbeiten”, um den Auslöser zu bearbeiten
  6. Ändere den Definierer von [user @ localhost] zu root @ localhost

Ich hoffe es hilft

Ich habe den gleichen Fehler nach dem Update von MySQL bekommen.

Der Fehler wurde nach diesem Befehl behoben:

 mysql_upgrade -u root 

mysql_upgrade sollte bei jedem Upgrade von MySQL ausgeführt werden. Es überprüft alle Tabellen in allen databaseen auf Inkompatibilitäten mit der aktuellen Version von MySQL Server. Wenn eine Tabelle eine mögliche Inkompatibilität aufweist, wird sie überprüft. Wenn irgendwelche Probleme gefunden werden, wird die Tabelle repariert. mysql_upgrade aktualisiert auch die Systemtabellen, damit Sie neue Privilegien oder functionen nutzen können, die möglicherweise hinzugefügt wurden.

Das wurde durch Ausführen der folgenden Kommentare behoben.

 grant all on *.* to 'web2vi'@'%' identified by 'root' with grant option; FLUSH PRIVILEGES; 

Wenn Sie some_other anstelle von web2vi , müssen Sie den Namen entsprechend ändern.

Der Benutzer ‘web2vi’ existiert nicht auf Ihrem mysql Server.

Siehe http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html#error_er_no_such_user

Wenn dieser Benutzer vorhanden ist, überprüfen Sie, auf welche Server er zugreifen kann, obwohl ich dachte, dass dies ein anderer Fehler wäre (zB web2vi @ localhost, aber Sie greifen auf die db als web2vi @% zu)

schnelle Lösung, um zu umgehen und die Datei ablegen:

 mysqldump --single-transaction -u root -p xyz_live_db > xyz_live_db_bkup110116.sql 

Meine 5 Cent.

Ich hatte denselben Fehler, als ich versuchte, aus einer Ansicht auszuwählen.

Problem scheint jedoch zu sein, dass diese Ansicht aus einer anderen Ansicht ausgewählt wurde, die von einer Sicherung von einem anderen Server wiederhergestellt wurde.

und in der Tat, JA, Benutzer war ungültig, aber war nicht offensichtlich, von dem ersten Blick.

Ich hatte das gleiche Problem mit Root-Benutzer und es funktionierte für mich, als ich ersetzte

 root@% 

durch

 root@localhost 

Wenn der Benutzer ‘web2vi’ von ‘localhost’ aus eine Verbindung herstellen kann, können Sie Folgendes versuchen:

 web2vi@localhost 

Ich bin aus der Ferne mit der database verbunden.

Versuchen Sie, Ihre Prozedur als SECURITY INVOKER

Mysql Standard setzt Prozeduren Sicherheit als “DEFINER” (CREATOR OF) .. Sie müssen die Sicherheit auf den “Invoker” setzen.

In meinem Fall hatte die Tabelle einen Trigger mit einem DEFINER-Benutzer, der nicht existierte.

 grant all on *.* to 'username'@'%' identified by 'password' with grant option; 

Beispiel:

 grant all on *.* to 'web2vi'@'%' identified by 'password' with grant option; 

Ihre Ansicht “view_quotes” wurde möglicherweise aus einer anderen database, in der “web2vi” ein gültiger Benutzer ist, in eine database kopiert, in der “web2vi” kein gültiger Benutzer ist.
Fügen Sie entweder den “web2vi” -Benutzer zur database hinzu oder ändern Sie die Ansicht (normalerweise wird der DEFINER = ‘web2vi’ @ ‘%’ – Teil entfernt und die Ausführung des Skripts führt zum Erfolg)

Sie können dies versuchen:

 $ mysql -u root -p > grant all privileges on *.* to `root`@`%` identified by 'password'; > flush privileges; 

Von der MySQL-Referenz von CREATE VIEW :

Die DEFINER- und SQL SECURITY-Klauseln geben den Sicherheitskontext an, der beim Überprüfen der Zugriffsrechte zum Zeitpunkt des Aufrufs der Ansicht verwendet werden soll.

Dieser Benutzer muss existieren und ist immer besser, ‘localhost’ als Hostname zu verwenden. Ich denke also, wenn Sie überprüfen, dass der Benutzer existiert und ändern Sie es auf “localhost” in der Ansicht erstellen, haben Sie diesen Fehler nicht.

Gehen Sie in den Abschnitt für die Bearbeitungsroutine und ändern Sie im unteren Bereich den Sicherheitstyp von Definer zu Invoker.

Das Problem ist klar – MySQL kann keinen Benutzer als Definierer finden.

Dieses Problem trat auf, nachdem ich das databasemodell vom Entwicklungsserver synchronisiert, auf localhost angewendet, Änderungen am Modell vorgenommen und es dann erneut auf localhost angewendet hatte. Anscheinend wurde eine Ansicht (ich modifiziert) definiert und ich konnte meine lokale Version nicht aktualisieren.

So reparieren (einfach) :

Hinweis: Es beinhaltet Löschen, so funktioniert es gut für Ansichten, aber stellen Sie sicher, dass Sie Daten gesichert haben, wenn Sie dies in Tabellen versuchen.

  1. Melden Sie sich als root bei der database an (oder was auch immer für Änderungen ausreicht).
  2. Löschen Sie die Ansicht, Tabelle oder was auch immer Sie Probleme haben.
  3. Synchronisieren Sie Ihr neues Modell – es wird sich nicht über etwas beschweren, das jetzt nicht existiert. Möglicherweise möchten Sie den SQL SECURITY DEFINER- Teil aus der Elementdefinition entfernen, mit der Sie Probleme hatten.

PS Dies ist weder eine richtige noch eine optimale Allround-Lösung. Ich habe es gerade als eine mögliche (und sehr einfache) Lösung veröffentlicht.

Ich hatte vor genau demselben Problem vor Minuten, ich lief in dieses Problem nach dem Löschen eines unbenutzten Benutzers aus mysql.user Tabelle, aber tun eine Alter-Ansicht behoben, hier ist ein praktischer Befehl, der es sehr einfach macht:

 SELECT CONCAT("ALTER DEFINER=`youruser`@`host` VIEW ", table_name," AS ", view_definition,";") FROM information_schema.views WHERE table_schema='databasename' 

Mischen Sie dies mit der mysql-Befehlszeile (vorausgesetzt, * nix, nicht vertraut mit Windows):

 > echo above_query | mysql -uuser -p > alterView.sql > mysql -uuser -ppass databasename < alterView.sql 

Hinweis: Der Befehl erzeugt und fügt SELECT CONCAT für die Datei hinzu, wodurch mysql -uuser -ppass databasename < alterView.sql fehlschlägt, wenn Sie ihn nicht entfernen.

Quelle: https://dba.stackexchange.com/questions/4129/modify-definer-on-many-views

Eine oder mehrere Ihrer Ansichten wurden von einem anderen Benutzer erstellt / registriert. Sie müssen den Eigentümer der Ansicht überprüfen und:

  1. Erstellen Sie den Benutzer neu. wie die anderen Antworten sagen. oder
  2. Erstellen Sie die Ansichten neu, die vom Benutzer 'web2vi' mithilfe von ALTER VIEW erstellt wurden

Ich hatte dieses Problem einmal.

Ich habe versucht, Ansichten von BD1 zu BD2 mit SQLYog zu migrieren. SQLYog erstellte die Sichten in der anderen database (DB2) neu, behielt aber den Benutzer von BD1 (sie waren anders). Später wurde mir klar, dass die Ansichten, die ich in meiner Abfrage verwendete, den gleichen Fehler hatten wie Sie, selbst wenn ich keine Ansicht erstellte.

Ich hoffe das hilft.

Wenn dies eine gespeicherte Prozedur ist, können Sie Folgendes tun:

 UPDATE `mysql`.`proc` SET definer = 'YournewDefiner' WHERE definer='OldDefinerShownBefore' 

Aber das ist nicht ratsam.

Für mich ist eine bessere Lösung, den Definierer zu erstellen:

 create user 'myuser' identified by 'mypass'; grant all on `mytable`.* to 'myuser' identified by 'mypass'; 

Wenn mysql.proc leer ist, aber das System immer bemerkt “user@192.168.%” für Tabellenname no exist, dann root einfach in der mysql-Befehlszeile und tippe:

 CHECK TABLE `database`.`table_name` QUICK FAST MEDIUM CHANGED; flush privileges; 

Über!

Warum bekomme ich diesen Fehler? Wie repariere ich es?

Ich habe eine Stunde gebraucht, bis ich eine Entscheidung für ein Problem wie dieses gefunden habe. Aber in meinem Fall habe ich das ausgeführt:

 mysql> UPDATE `users` SET `somefield` = 1 WHERE `user_id` = 2; ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist 

Wenn Sie das Problem wirklich finden möchten, führen Sie diese Befehle nacheinander aus:

 SHOW PROCEDURE STATUS; SHOW FUNCTION STATUS; SHOW TRIGGERS; SHOW FULL TABLES IN database_name WHERE TABLE_TYPE LIKE 'VIEW'; 

… und nach jedem von ihnen suchen Sie nach dem Feld “Definierer”.

In meinem Fall war es bärtiger alter Auslöser, den jemand von Entwicklern vergessen hat zu löschen.

Dies ist mir passiert, nachdem ich einen Dump unter Windows 10 mit MYSQL Workbench 6.3 Community importiert habe, mit “root @% does not exist”. Obwohl der Benutzer existiert. Zuerst habe ich versucht, den DEFINER zu kommentieren, aber das hat nicht funktioniert. Ich habe dann eine Zeichenfolge ersetzt “root @%” mit “root @ localhost” und importierte den Dump erneut. Das hat den Trick für mich gemacht.

Der databasebenutzer scheint auch die Groß- / Kleinschreibung zu beachten. Obwohl ich einen ‘@’% – Benutzer hatte, hatte ich keinen ROOT ‘@’% – Benutzer. Ich änderte den Benutzer über Workbench in Großbuchstaben und das Problem wurde behoben!

In meinem Fall hatte ich einen Trigger auf dieser Tabelle, bei dem ich keine Daten mit dem gleichen Fehler aktualisieren konnte.

MySQL-Fehler 1449: Der als Definierer angegebene Benutzer existiert nicht

Die Lösung bestand darin, die Auslöser in dieser Tabelle zu löschen und sie erneut zu erstellen. Dadurch wurde das Problem behoben, da der Auslöser mit einem anderen Benutzer von einem anderen Server ausgetriggers und der Benutzername auf dem neuen Server geändert wurde, nachdem das Hostingunternehmen geändert wurde. das sind meine 2 Cent

Ich kam wegen des gleichen Problems hierher, ich konnte nirgendwo in meinem Code finden, wo ein bestimmter Benutzer die Aktion ausgeführt hat. anscheinend war es von einem Auslöser, der einen Benutzer benutzte, der lang gelöscht wurde (db wurde von einer älteren Version wieder hergestellt), so für den Fall, dass Sie verwirrt sind, wie ich war, casting Sie einen Blick auf Ihre Db-Ereignisse / Auslöser / Routinen. hoffe das wird jemandem helfen.