exported SQL is corrupted

[kukoman]

Steps to reproduce

1. create a new row with the following SQL: insert.sql.txt
2. copy the html content from html-content.html.txt and paste it into the column "html_content" of the row created in step 1 (click on the row in phpmyadmin and paste the content; do NOT use SQL for that)
3. export the row as SQL (or a whole DB) - for simplicity you can skip this step and use the file attached update-after-export.sql.txt
4. try to feed the exported SQL back into phpmyadmin (click SQL tab and paste the SQL) - you can use the following update SQL: update-after-export.sql.txt
5. the import will fail as the exported SQL is malformed, for both update and insert

Exporting DB/table with mysql cli will produce a valid SQL.

Expected behaviour

Export should produce a valid SQL.

Actual behaviour

Error after running the SQL
Static analysis:

1 errors were found during analysis.

Ending quote ' was expected. (near "" at position 3947)

MySQL said: Documentation

1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''<!-- etm:B10:start -->\n<table data-etm-rname="B10" data-etm-rtype="row" class=' at line 1

Server configuration

Operating system:
Debian latest stable
Redhat 6.8

Web server:
Apache/2.4.10
Apache/2.2.15

Database:
MySQL 5.6.30

PHP version:
PHP 7.0.9

phpMyAdmin version:
4.6.3
4.7.0-dev

please see attached files required to reproduce the issue

insert.sql.txt
html-content.html.txt
update-after-export.sql.txt

[devenbansod]

This is caused because the double-quotes " are not properly escaped while exporting.
I think we should provide a method in Database interface to use the functions like mysqli_real_escape_string to escape strings while exporting.

[marceloagil]

Hi, just bringing this issue back because I'm also facing same problem. What should we do with this corrupted exported database? It's gone? No workaround?

[ibennetch]

@Agimovel Which phpMyAdmin version are you using to perform your export? This has been fixed since November of 2016.

[marceloagil]

Hi, I found out to be another issue.

One of db tables had a namespace, and that namespace broke the import from that line to the rest of them.

Should I open an issue? We don't use tables with namespaces, I don't even think that's possible or secure. I have no idea why such table was on this db test, maybe one of our tests failed creating this abomination.