[patrickq]

Let me try to make my point once again (and I promise I'll stop there :-)):

1. I don't think it can ever make sense to create a script which you know at the time it is created that it will not run successfully. This is doubly true when that same script starts its life by dropping the table which it will then fail to restore …

2. More to the point: note that MySQLDump is apparently aware of the limitation on MySQL statement length. As a result, if you run mysqldump with default options, it too will generate long INSERT statements, BUT (and here comes the major difference) only as long as the net_buffer_length parameter. This parameter defaults to 1047551 so the result for each table is a series of INSERT statements each of that length or less, and the script works.

If I may, I suggest that you indeed keep the default options as they are, if you think it's the best default for most users, but internally limit the length of each statement to what MySQL allows.

[patrickq]

Actually, now that I am re-checking it seems that:

1. SQLyog doesn't use double quotes (“), it uses ` (correctly)

2. In my attempts at finding the problem, I mistakenly used ' instead of `

In fact, I got confused and this is actually a MySQL Administrator bug! The bug is valid, MySQL Administrator does use ” and the script doesn't work, but that's not a SQLyog bug, sorry …

I was trying to combine using MySQL Administrator for scheduled backups (until SQLyog implements scheduled backups), while using SQLyog for everything else (such as one-time backups or restores). Looks like for now I will have to edit the MySQLAdministrator scripts, or else use one-time backups done via SQLyog.

[Author]

Posts