2

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 > ~/dump.sql

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

mysql -uroot -pMyPwd < 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:

enter image description 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.

-1

I got 2 comments that hinted me that:

  1. This problem might not be reproducible again if I do a second mysqldump.
  2. 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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.