Trying to restore SQL file from mysqldump, results in syntax error I ran the following sqldump call in a MySQL 5.7 instance (Windows OS):

mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=1 --routines -A &gt; ~/dump.sql


I copied the result in a MySQL 5.7 instance (Linux OS), and executed it via:

mysql -uroot -pMyPwd &lt; dump.sql


But I got the following error:


  ERROR 1064 (42000) at line 813: 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 '917,0.31000000,267.21000000,'2015-07-08 17:44:39',88758,'BK1','BK1',49208,4921' at line 1


There are some characters in the error message that I haven't been able to copy, so I paste an image here:



So I open the (big) file in nano, and I find the fragment which has this weird characters:

...(49171,0.87000000,267.28000000,'2015-07-08 17:42:48',88671,'BK1','BK1',49167,49170,63,64,'BK11432145524','BK11432145533','xxxxxx',0,0.00000000,0.00000000,0.00000000,0.00000000),(^T9^R17,0.31000000,267.21000000,'2015-07-08 17:44:39',88758,'BK1','BK1',49208,49216,63,64,'BK11432145637','BK11432145661','xxxxxx',0,0.00000000,0.00^P00000,0.0000000^P,0.00000000),(4^Y^R^W6,0.19000000,267.14000000,'2015-07-08 17:47:02',88875,'BK1','BK1'...


As you can see, it seems the first value of a row seems to have a weird element ^T9^R17 instead of a normal integer like the row before (49171).

Tried to run dos2unix on the file as recommended by @Verace, and this is the result:

$ dos2unix dump.sql 
dos2unix: Binary symbol 0x14 found at line 813
dos2unix: Skipping binary file dump.sql


Why is this happening? The type of the first column is bigint(20) NOT NULL.
I got 2 comments that hinted me that:


This problem might not be reproducible again if I do a second mysqldump.
The copy of the file from one place to another might have corrupted the file.


So then to ensure (1) was not the case, I tried to mysqldump again, and to make sure (2) didn't happen, I compiled the file before transferring it to another computer (so that if it gets corrupted, at least I would know when trying to decompress it).

The result was: success. It works now. So I suspect it was a glitch in the matrix.
Thanks for all the people that helped.