Bug #65222 mysql export does not work well.
Submitted: 7 May 2012 10:20 Modified: 31 Aug 2012 6:09
Reporter: Young-jun Song Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S2 (Serious)
Version:5.2.39 OS:Windows (windows7 64bit)
Assigned to: CPU Architecture:Any
Tags: escape, export

[7 May 2012 10:20] Young-jun Song
Description:
When I try export the result from "select * from `some_db`;", the exported data has wrong escaped result.

If there is "text\r\nanother text" in some column, exported result is expected "text\\r\\nanother text". but it has "text\r\nanother text".

When I insert "text\r\nanother text" filed, Workbench create the sql "INSERT INTO `some_db` (`engine_url`) VALUES ('test\\r\\nanother text');"' but export is not.

thanks you.

How to repeat:

Step 1. make table has '\r\n' data.
Step 2. select made table.
Step 3. click export button to export selected rows.
Step 4. Export as sql
Step 5. open the exported sql file.

Suggested fix:

fix escape.
[11 May 2012 10:11] Valeriy Kravchuk
Problematic file exported

Attachment: bug65222.sql (text/x-sql), 146 bytes.

[11 May 2012 10:13] Valeriy Kravchuk
Thank you for the bug report. Indeed, when I created table with data like this:

mysql> create table ttext(id int primary key, t varchar(100));
Query OK, 0 rows affected (0.97 sec)

mysql> insert into ttext values (1, 'text\r\nmore text');
Query OK, 1 row affected (0.16 sec)

mysql> select * from ttext;
+----+-----------------+
| id | t               |
+----+-----------------+
|  1 | text
more text |
+----+-----------------+
1 row in set (0.01 sec)

and then exported results of SELECT * from it in Workbench, I've got INSERTs without proper escapes (see file uploaded). This is a bug (maybe it was reported earlier, but I can not find a duplicate at the moment).
[31 Aug 2012 6:09] Philip Olson
Fixed as of the upcoming 5.2.43, and here's the changelog entry:

 The MySQL Export wizard would not escape hardcoded newlines in
 the generated SQL, but they are now escaped. For example, a
 '\n' now remains as '\n' in the exported query, when before 
 it was expanded.

Thank you for the report.