Bug #72312 Unable to export database in MySQL Workbench 6.1.4
Submitted: 11 Apr 2014 2:26 Modified: 27 Aug 2014 21:48
Reporter: Jason Harp Email Updates:
Status: Closed Impact on me:
Category:MySQL Workbench Severity:S2 (Serious)
Version:6.1.4, 6.1.7 OS:Microsoft Windows (7 Pro)
Assigned to: CPU Architecture:Any

[11 Apr 2014 2:26] Jason Harp
Unable to export database with the MySQL Workbench 6.1.4 in either Dump Project or Self-Contained.  

Export fails with "mysqldump: [ERROR] unknown variable 'delayed-insert=FALSE'"

Target DB is 5.7.3-m13 InnoDB

How to repeat:
Attempt to export a database with the MySQL Workbench.

Suggested fix:
Remove the delayed-insert parameter if it is no longer supported in databases 5.6 and above.
[25 Apr 2014 19:14] Alfredo Kojima
Do you have something configured in Preferences -> Administration -> Path to mysqldump Tool?
[9 May 2014 14:21] Timothy Bomgardner
I have the same problem running 5.7.3, Workbench  There are no options specified in Preferences/Admin/Path to mysqldump tool:

C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqldump.exe
[17 Jun 2014 0:21] Jason Harp
10:13:41 Dumping shearer_archive (all tables)
Running: D:\mysql\bin\mysqldump.exe --defaults-file="c:\users\harpj\appdata\local\temp\tmpgb97wi.cnf"  --set-gtid-purged=OFF --max_allowed_packet=1G --delayed-insert=TRUE --host= --user=shearer --compress=TRUE --port=3306 --default-character-set=utf8 --routines "shearer_archive"
mysqldump: [ERROR] unknown variable 'delayed-insert=TRUE'

Operation failed with exitcode 7
10:13:42 Export of D:\SQL Dumps\Dump20140617.sql has finished with 1 errors

Workbench 6.1.611834 Build 1642
[27 Jun 2014 22:28] Matthew Hale
I see the same behavior on OS X with Workbench 6.1.6 and 6.1.7, using MySQL 5.7.4.
[30 Jun 2014 10:37] MySQL Verification Team
Thank you for the feedback.
Verified as described on 6.1.7

Running: D:\ushastry\mysql-advanced-5.7.5-m15-winx64\bin\mysqldump.exe --defaults-file="c:\users\ushastry\appdata\local\temp\tmp_qse1g.cnf"  --max_allowed_packet=1G --delayed-insert=TRUE --host= --user=ushastry --port=3307 --default-character-set=utf8 --skip-triggers  --no-data  --no-create-db --no-create-info --routines --events "test"
mysqldump: [ERROR] unknown variable 'delayed-insert=TRUE'

Operation failed with exitcode 7

The error occurs when the mysqldump location is configured to point to the version of mysqldump in MySQL 5.7.5.

When the mysqldump location is left as the default, the dump will continue, but warned about the version mismatch:


mysqldump Version Mismatch

/Applications/MySQLWorkbench.app/Contents/MacOS/mysqldump is version 5.6.17, but the MySQL Server to be dumped has version 5.7.5-m15.
Because the version of mysqldump is older than the server, some features may not be backed up properly.
It is recommended you upgrade your local MySQL client programs, including mysqldump to a version equal to or newer than that of the target server.
The path to the dump tool must then be set in Preferences -> Administrator -> Path to mysqldump Tool:
[30 Jun 2014 10:40] MySQL Verification Team
Bug #73137 marked as duplicate of this
[27 Aug 2014 21:48] Philip Olson
Fixed as of the upcoming MySQL Workbench 6.2.2 release, and here's the changelog entry:

When exporting a database, MySQL Workbench now checks and notifies the user
when the bundled or configured "mysqldump" is older than the target MySQL
version, and prompts the user to set "Path to mysqldump Tool" in
MySQL Workbench to the appropriate version.

Thank you for the bug report.
[23 Oct 2015 9:55] Axel Werner
i run workbench 6.3.5 build 201 CE 32bit on a 64bit windows 7 pro german and experienve the same problem as described here. 

The "export" of a database that is run on a remote linux SLES 11.sp3 mysql database (as it comes with SLES 11 sp3) failes with 

11:53:39 Dumping pdfreceiver (all tables)
Running: mysqldump.exe --defaults-file="c:\users\username\appdata\local\temp\tmpakqmrj.cnf"  --set-gtid-purged=OFF --delayed-insert=FALSE --host=localhost --protocol=tcp --user=root --port=2886 --default-character-set=utf8 --single-transaction=TRUE --routines --events "dbschemaName"
mysqldump: [ERROR] unknown variable 'delayed-insert=FALSE'

Operation failed with exitcode 7
11:53:39 Export of \\ad\home\username\Desktop\Dump20151023.sql has finished with 1 errors

how or where to remove that "--delayed-insert=FALSE" parameter from the dump ?
[24 Oct 2015 16:44] Christophe LARATTE
Exactly the same trouble in the same conditions than Axel Werner reported [23 Oct 9:55]:

- workbench 6.3.5 build 201 CE (64 bits) Community on Windows 10

Error message:

18:30:16 Dumping of30_fr_modele-societe-ulm (validity_type)
Running: mysqldump.exe --defaults-file="c:\users\christ~1\appdata\local\temp\tmp08eypn.cnf"  --set-gtid-purged=OFF --delayed-insert=FALSE --host=localhost --protocol=tcp --user=root --port=43212 --default-character-set=utf8 --single-transaction=TRUE --no-create-info=TRUE --skip-triggers "XXX"
mysqldump: [ERROR] unknown variable 'delayed-insert=FALSE'

Operation failed with exitcode 7
18:30:17 Export of C:\Users\Christophe\Documents\dumps\Dump20151024.sql has finished with 1 errors

I tried again after having changed the settings in "Edit > Preferences > Modeling > MySQL" field "Default target MySQL Version" from 5.6 to 5.7, with no result.
[28 Oct 2015 12:22] A de koning
This is an ANCIENT Problem THAT STILL IS NOT SOLVED in 6.3!

Why NOT ??????

I did a clean install of everything and this error comes up.

Dearest Mysql Workbench  programmer if this is deprecated just ignore the setting. That shouldn't be to difficult would it?

It makes MYSQL useless for developers like me.
[28 Oct 2015 19:34] MySQL Verification Team
http://bugs.mysql.com/bug.php?id=79004 marked as duplicate of this one.
[29 Oct 2015 1:09] Davy Machado
[29 Oct 2015 22:15] Christophe LARATTE
Thanks for the temp fix:

It works!
[15 Dec 2015 12:29] MySQL Verification Team
http://bugs.mysql.com/bug.php?id=79644 marked as duplicate of this one.
[9 Mar 2016 15:51] Kristiaan Bennett
This is still a problem with 6.3.5 build 201 CE (64 bits) yes it does say bits

I've had to apply the StackOverflow fix previously mentioned in order to resolve this issue.
[1 Apr 2016 20:26] Philip Olson
It appears this bug is getting mixed with a related bug (see duplicates for details) but it appears the bug behind most of the recent comments was fixed in Workbench 6.3.6.