WinXP , MySQL Workbench 6.1.7 (последняя версия, поддерживающая WinXP).
Выполняю трансфер данных из удалённой базы (Debian + mysql) в локальную. На удалённом сервере создал пользователя user@% и разрешил удалённый коннект. Из MySQL Workbench Reverse Engineer из удалённой базы выполняется нормально - схема БД нормально читается, строится EER-диаграмма и пр. Т.е. с коннектом и с правами всё в порядке.

Далее пытаюсь выполнить трансфер данных из удалённой базы в локальную ( Schema Transfer Wizzard ). В процессе транфера получаю ошибку (в тексте ошибки имя БД заменил на database ):
авторERROR: Reverse Engineering: QueryError("Error executing 'SHOW TABLES FROM ```database```'
Unknown database '`database`'.
SQL Error: 1049"): error calling Python module function DbMySQLRE.reverseEngineer
Failed Предварительно на всякий случай проверил следующее :
1 . На удалённом сервере mysql зашёл под тем же пользователем, под которым выполняю трансфер данных, и нормально выполнил запрос SHOW TABLES FROM `database` - получил список таблиц
2 . Создал 2 локальных соединения и попробовал выполнить трансфер данных из локальной БД в локальную БД - та же самая ошибка
3 . Попробовал выполнить трансфер из тестовой таблицы test (которую создаёт mysql workbench при установке) - та же самая ошибка

А теперь возвращаемся к сообщению об ошибке. Видно, что обратные апострофы включены в название БД - поэтому и генерируется ошибка, что БД не существует.
Сделал следующее (тестирую трансфер данных из локальной БД в локальную БД) :

1 . В настройках локального mysql вместо режима TRADITIONAL (для названий объектов БД используются обратные апострофы) указал режим ANSI_QUOTES (для названий объектов БД используются двойные кавычки и апострофы):

Перезапустил локальный mysql . На всякий случай проверил корректность считывания этой настройки в Server - Options File и непосредственно в Server - Status And System Variables - System Variables . Выполняю трансфер данных - та же ошибка.

2 . В настройках mysql workbench на вкладке " Model: MySQL " в поле " SQL_MODE to be used in generated scrips " вместо " TRADITIONAL,ALLOW_INVALID_DATES " указываю " ANSI_QUOTES,ALLOW_INVALID_DATES ". На всякий случай перезагружаю mysql workbench . Выполняю трансфер данных - та же ошибка.

3 . В настройках mysql workbench на вкладке " General " в поле " Interactive GRT Shell language " вместо " python " указываю " lua ". На всякий случай перезагружаю mysql workbench . Выполняю трансфер данных - та же ошибка.

Во всех случаях (даже в режиме ANSI_SQL ) имена баз данных в Schema Transfer Wizzard отображаются в обратных апострофах.

Почему mysql workbench ( Schema Transfer Wizzard ) включает обратные апострофы в название БД ?
Или это глючит питоновский модуль ?

автор1. В настройках локального mysql вместо режима TRADITIONAL (для названий объектов БД используются обратные апострофы) указал режим ANSI_QUOTES (для названий объектов БД используются двойные кавычки и апострофы):Поправлюсь. TRADITIONAL здесь не в тему. Это не режим, противоположный ANSI_QUOTES, а комбинация режимов .
Для отключения режима ANSI_QUOTES достаточно исключить эту константу и списка sql_mode .

P.S . Т.к. замечание не касается сабжевой проблемы, сабжевый вопрос остаётся в силе.

авторгипотеза с потолка - sql_quote_show_create тут никак играть не может? Нет, sql_quote_show_create = 0 не помогает. Та же самая ошибка:
Unknown database '`database`'

Возможно, глючит сам Workbench . Либо конкретно версия 6.1.7.
В любом случае, проще будет батник написать с 3 командами - 2 раза mysqldump + удаление скачанной базы. И не нужно никаких Workbench 'ей...

P.S . Только пароль придётся засветить. В этом самом батнике. Не есть хорошо...

авторВозможно, глючит сам Workbench. Либо конкретно версия 6.1.7.
Так и есть. Это bug вот этой конкретной версии - 6.1.7.
В версии 6.1.6 никаких проблем не наблюдается. А также и в более ранних. Проверил 5 версий. Проблема только с 6.1.7.

На официальном сайте доступны для скачивания только последние подверсии ( 6.2.5 , 6.1.7 , 6.0.9 и 5.2.47 ). Версия mysql workbench 6.1.6 можно скачать, например, отсюда .

P.S . Только скачивает базу mysql workbench медленно. По сравнению с импортом через mysqldump (в дампе выполняется оптимизация последовательности запросов, отключение проверок и пр.).

---
Итог: для WinXP последние версии mysql следующие:
Сервер mysql = 5.6.4
mysql workbench = 6.1.6
MySQL Utilities = 1.4.4

авторP.S. Только скачивает базу mysql workbench медленно.
Ещё артефакт такой наблюдается. Небольшой процент запросов на локальный апдейт имеет вот такой вид:

Т.е. получается, что число записей, которое локальный mysql workbench получил от удалённого mysql , меньше, чем фактическое число импортированных записей. Можно объяснить тем, что с момента получения числа записей до момента фактической выборки записей проходит некоторое время, в течение которого в таблицу успевают добавиться новые записи. Ну а mysql workbench сравнивает эти "количества" и пишет в логах FAILED, если числа не совпадают (даже если число импортированных записей "превышает" их количество).

В то же время в одной из таблиц проверил - новые записи не добавлялись, но при этом mysql workbench в логах написал:

В таблице как было 5 записей, так 5 записей и осталось. Т.е. здесь получается, что при получении числа записей mysql workbench по каким-то причинам получил 4 вместо 5...

авторА в воркбенче ты его типа не засвечиваешь... какая в пень разница? опять же кто тебе мешает интерактивно на старте в самом батнике запросить пароль? ну будет он в памяти во время исполнения - так ещё до среды конкретного процесса достучаться нужно... а в тексте его не будет. Так mysql workbench его тоже в открытом виде нигде не хранит. И вводить ничего не нужно.
А если в батнике пароль запрашивать, тогда чем он лучше варианта с mysql workbench ? Необходим такой вариант: компьютер загружается, открывается phpStorm и... начинаешь работать с проектом. При это локальная база к этому моменту уже будет синхронизирована с продакшеном.

В mysql workbench как-то много телодвижений нужно делать. Выбирать соединения, тыкать по кнопкам, снимать галку " Migrate MyISAM tanles to InnoDB " (достаёт)...