Ошибка MySQL 1449: пользователь, указанный как определитель, не существует

Это обычно происходит при экспорте представлений/триггеров/процедур из одной базы данных или сервера в другой, поскольку пользователь, создавший этот объект, больше не существует.

У вас есть два варианта:

1. Измените DEFINER

Это, возможно, проще всего сделать при первоначальном импорте объектов базы данных, удалив любые операторы DEFINER из дампа.

Изменение определителя позже является более сложным:

Как изменить определитель для представлений

• Запустите этот SQL для генерации необходимых операторов ALTER

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

• Скопируйте и запустите инструкции ALTER

Как изменить определитель для хранимых процедур

Пример:

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

Будьте осторожны, потому что это изменит все определители для всех баз данных.

2. Создайте отсутствующего пользователя

Если вы обнаружили следующую ошибку при использовании базы данных MySQL:

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

Тогда вы можете решить это, используя следующее:

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

Из http://www.lynnnayko.com/2010/07/mysql-user-specified-as-definer-root.html

Это работало как шарм - вам нужно только изменить someuser на имя пропавшего пользователя. На локальном сервере-разработчике обычно можно использовать root.

Также рассмотрите вопрос о том, действительно ли вам нужно предоставить разрешения пользователя ALL или они могут сделать меньше.

Пользователь, который изначально создал представление или процедуру SQL, был удален. Если вы воссоздаете этого пользователя, он должен устранить вашу ошибку.

Если пользователь существует, то:

mysql> flush privileges;

Создайте удаляемого пользователя следующим образом:

mysql> create user 'web2vi';

или

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

Я получил ту же ошибку после обновления mysql.

Ошибка была исправлена после этой команды:

mysql_upgrade -u root

mysql_upgrade должен выполняться каждый раз при обновлении MySQL. Он проверяет все таблицы во всех базах данных на предмет несовместимости с текущей версией MySQL Server. Если найденная таблица имеет возможную несовместимость, она проверяется. Если обнаружены какие-либо проблемы, таблица будет восстановлена. mysql_upgrade также обновляет системные таблицы, чтобы вы могли использовать новые привилегии или возможности, которые могли быть добавлены.

Решение - это всего лишь однострочный запрос, как показано ниже:

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

Замените ROOT своим именем пользователя mysql. Замените PASSWORD своим паролем mysql.

Выполните следующие действия:

• Перейдите в PHPMyAdmin
• Выберите свою базу данных
• Выберите таблицу
• В верхнем меню Нажмите "Триггеры"
• Нажмите "Изменить", чтобы изменить триггер
• Измените определитель с [user @localhost] на root @localhost

Надеюсь, что это поможет

Для будущих googlers: у меня есть аналогичное сообщение, пытающееся обновить таблицу в базе данных, которая не содержит представлений. После некоторого копания оказалось, что я импортировал триггеры на эту таблицу, и это были вещи, определенные несуществующим пользователем. Сбрасывание триггеров решило проблему.

Исправлено, выполнив следующие комментарии.

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

если вы получаете some_other вместо web2vi, тогда вы должны соответствующим образом изменить имя.

быстро исправить работу и выгрузить файл:

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

Пользователь 'web2vi' не существует на вашем сервере mysql.

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

Если этот пользователь существует, проверьте, на каких серверах он может получить доступ, хотя я бы подумал, что это будет другая ошибка (например, у вас может быть web2vi @localhost, но вы получаете доступ к db как web2vi @% (во что угодно )

Попробуйте установить процедуру как SECURITY INVOKER

Mysql default устанавливает безопасность процедур как "DEFINER" (CREATOR OF).. вы должны установить защиту для "invoker".

У меня была такая же проблема с пользователем root, и он работал у меня, когда я заменил

root@%

по

root@localhost

Итак, если пользователю 'web2vi' разрешено подключаться из 'localhost', вы можете попробовать:

web2vi@localhost

Я подключен удаленно к базе данных.

Мои 5 центов.

У меня была такая же ошибка, когда я пытался выбрать из представления.

Однако проблема заключается в том, что это представление, выбранное из другого представления, которое было восстановлено из резервной копии с другого сервера.

и на самом деле, ДА, пользователь был недействителен, но не был очевиден с первого взгляда.

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

Пример:

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

В моем случае таблица имела триггер с пользователем DEFINER, которого не было.

Вы можете попробовать следующее:

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

Ваше мнение, "view_quotes", возможно, было скопировано из другой базы данных, где "web2vi" является допустимым пользователем в базе данных, где "web2vi" не является допустимым пользователем.
Либо добавьте пользователя "web2vi" в базу данных, либо измените представление (обычно удаление части DEFINER = 'web2vi' @'%' и выполнение script сделает трюк)

Это произошло со мной после того, как я импортировал дамп в Windows 10 с MySQL Workbench 6.3 Community, а "root @% не существует". Хотя пользователь существовал. Сначала я попытался прокомментировать DEFINER, но это не сработало. Затем я заменил строку "root @%" на "root @localhost" и повторно импортировал дамп. Это сделало трюк для меня.

Почему я получаю эту ошибку? Как это исправить?

Я потратил час до того, как нашел решение для такой проблемы. Но в моем случае я запустил это:

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

Если вы действительно хотите найти проблему, просто запустите следующие команды:

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

... и после каждого из них найдите поле "определитель".

В моем случае это был бородатый старый триггер, который кто-то из разработчиков забыл удалить.

когда mysql.proc пуст, но система всегда замечает "[email protected].%" для имени таблицы, нет, вы просто root в командной строке mysql и введите:

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

над

Если это хранимая процедура, вы можете сделать:

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

Но это не рекомендуется.

Для меня лучшим решением является создание определителя:

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

Один или несколько видов, созданных/зарегистрированных другим пользователем. Вам нужно будет проверить владельца представления и:

• Восстановить пользователя; как говорят другие ответы. или
• Создайте представления, созданные пользователем 'web2vi', используя ALTER VIEW

У меня была эта проблема.

Я пытался перенести представления из BD1 в BD2, используя SQLYog. SQLYog воссоздал представления в другой базе данных (DB2), но он сохранил пользователя BD1 (они разные). Позже я понял, что представления, которые я использовал в моем запросе, имели ту же ошибку, что и вы, даже когда я не создавал никакого представления.

Надеюсь на эту помощь.

Проблема понятна - MySQL не может найти пользователя, заданного в качестве определителя.

Я столкнулся с этой проблемой после синхронизации модели базы данных с сервера разработки, применения ее к localhost, внесения изменений в модель и последующего повторного использования ее на localhost. По-видимому, было определено представление (я изменил), и поэтому я не смог обновить локальную версию.

Как исправить (легко) :

Примечание: он включает удаление, поэтому он отлично подходит для представлений, но убедитесь, что у вас есть резервная копия данных, если вы попробуете это в таблицах.

• Войдите в базу данных как пользователь root (или все, что имеет достаточную мощность для внесения изменений).
• Удалить представление, таблицу или все, с чем вы столкнулись.
• Синхронизируйте свою новую модель - она ​​не будет жаловаться на то, чего не существует сейчас. Вы можете удалить часть SQL SECURITY DEFINER из определения элемента, с которым у вас были проблемы.

P.S. Это не является ни правильным, ни лучшим решением. Я просто разместил его как возможное (и очень простое) решение.

У меня была одна и та же проблема минут назад, я столкнулся с этой проблемой после того, как удалил неиспользуемого пользователя из таблицы mysql.user, но вместо этого изменил его вид, вот удобная команда, которая делает ее очень простой:

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

Смешайте это с командной строкой mysql (предполагая * nix, не знакомый с окнами):

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

Примечание: команда генерирует и добавляет SELECT CONCAT в файл, делая mysql -uuser -ppass databasename < alterView.sql сбой, если вы не удалите его.

Источник: https://dba.stackexchange.com/questions/4129/modify-definer-on-many-views

Перейдите в раздел подпрограммы редактирования, а внизу измените тип безопасности с Definer на Invoker.

От ссылка MySQL CREATE VIEW:

В предложениях DEFINER и SQL SECURITY указан контекст безопасности, который будет использоваться при проверке прав доступа во время вызова представления.

Этот пользователь должен существовать и всегда лучше использовать "localhost" в качестве имени хоста. Поэтому я думаю, что если вы проверите, что пользователь существует и измените его на "localhost" при создании представления, у вас не будет этой ошибки.

Это произошло со мной после перемещения БД с одного сервера на другой. Сначала определитель использовал localhost и пользователя. На новом сервере у нас нет этого пользователя и хоста. Я взял резервную копию этого конкретного стола и удалил все триггеры вручную из phpmyadmin. После этого он отлично работает для меня.

В качестве дополнения, чтобы изменить определитель для TRIGGERS (ALTER не работает), вы можете сделать это следующим образом:

Создайте команду DROP и CREATE для каждого триггера:

SELECT CONCAT("DROP TRIGGER ", trigger_name, ";", " CREATE TRIGGER ", TRIGGER_NAME, " AFTER ", EVENT_MANIPULATION, " ON ", EVENT_OBJECT_SCHEMA, ".", EVENT_OBJECT_TABLE, " FOR EACH ROW ", ACTION_STATEMENT, ";") AS sqlCommand FROM information_schema.triggers WHERE EVENT_OBJECT_SCHEMA = "yourdatabase";

Выполните его в foreach. Я использую это в своем приложении, когда беру производственную базу данных на свою машину разработки и отправляю ее с помощью foreach по всем командам и автоматически создаю триггеры. Это дает мне возможность автоматизировать его.

Пример в PHP/Laravel:

    $this->info('DROP and CREATE TRIGGERS');
    $pdo = DB::connection()->getPdo();
    $sql = 'SELECT CONCAT("DROP TRIGGER ", trigger_name, ";", " CREATE TRIGGER ", TRIGGER_NAME, " AFTER ", EVENT_MANIPULATION, " ON ", EVENT_OBJECT_SCHEMA, ".", EVENT_OBJECT_TABLE, " FOR EACH ROW ", ACTION_STATEMENT, ";") AS sqlCommand FROM information_schema.triggers WHERE EVENT_OBJECT_SCHEMA = "mydatabase";';
    $stmt = $pdo->prepare($sql, [PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true]);
    $stmt->execute();
    $result = $stmt->fetchAll(PDO::FETCH_ASSOC);
    $stmt->closeCursor();

    foreach($result as $rs){
        $pdo = DB::unprepared($rs['sqlCommand']);
        break;
    }

Подсказка: я должен сделать это с pdo из-за проблемы с запросом буфера mysql, описанного здесь

Я пришел сюда по той же проблеме, я не смог найти нигде в моем коде, где какой-то пользователь делал это действие. по-видимому, это был из триггера, который использовал пользователя, который был давно удален (db был восстановлен из более старой версии) поэтому, если вы озадачены, как я, взгляните на ваши события/триггеры/подпрограммы. надеюсь, это поможет кому-то.

в моем случае у меня был триггер в этой таблице, что я не мог обновлять данные, получая ту же ошибку.

Ошибка MySQL 1449: пользователь, указанный как определитель, не существует

решение заключалось в том, чтобы удалить триггеры в этой таблице и снова создать их снова, это устранило проблему, поскольку триггер был сделан с другим пользователем с другого сервера, а имя пользователя изменилось на новом сервере после изменения компании-хостинга. что мои 2 цента

Пользователь базы данных также, похоже, чувствителен к регистру, поэтому, когда у меня был пользователь root @@%, у меня не было пользователя ROOT '@'%. Я изменил пользователя на верхний регистр с помощью инструментария, и проблема была решена!

вы можете создать пользователя с именем web2vi и предоставить все привилегии

Попробуйте следующее:

mysqldump --routines --single-transaction -u root -proot portalv3 > c:\portal.sql