Hi,
here is IMO a MySQL (at least 4.0.20) bug, but maybe we could put a workaround in the export logic.
If the last exported table has no data, the export file ends with those ANSI-style comments:
-- -- Dumping data from table table1 --
and MySQL gives an error on this!
No problem if the file ends with MySQL-style comments.
Marc
Hi
On Mon 13. 9. 2004 19:26, Marc Delisle wrote:
here is IMO a MySQL (at least 4.0.20) bug, but maybe we could put a workaround in the export logic.
If the last exported table has no data, the export file ends with those ANSI-style comments:
--
-- Dumping data from table table1
and MySQL gives an error on this!
No problem if the file ends with MySQL-style comments.
MySQL itself doesn't have problems with it (using command line), but phpMyAdmin does. So we should fix it somehow...
Michal C(ihar( a écrit:
Hi
On Mon 13. 9. 2004 19:26, Marc Delisle wrote:
here is IMO a MySQL (at least 4.0.20) bug, but maybe we could put a workaround in the export logic.
If the last exported table has no data, the export file ends with those ANSI-style comments:
--
-- Dumping data from table table1
and MySQL gives an error on this!
No problem if the file ends with MySQL-style comments.
MySQL itself doesn't have problems with it (using command line), but phpMyAdmin does. So we should fix it somehow...
Which version did you try?
But I tested it with command-line!
Marc
On Tue 14. 9. 2004 17:08, Marc Delisle wrote:
Which version did you try?
4.0.21
But I tested it with command-line!
Then I'd ignore this case :-)
On Mon 13. 9. 2004 19:26, Marc Delisle wrote:
here is IMO a MySQL (at least 4.0.20) bug, but maybe we could put a workaround in the export logic.
If the last exported table has no data, the export file ends with those ANSI-style comments:
--
-- Dumping data from table table1
and MySQL gives an error on this!
No problem if the file ends with MySQL-style comments.
The problem is that phpMyAdmin removes trailing space, so it is not valid ANSI comment then:
#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 '--' at line 3
I currently don't have time to track where the space is being trimmed...
Michal C(ihar( a écrit :
On Mon 13. 9. 2004 19:26, Marc Delisle wrote:
here is IMO a MySQL (at least 4.0.20) bug, but maybe we could put a workaround in the export logic.
If the last exported table has no data, the export file ends with those ANSI-style comments:
--
-- Dumping data from table table1
and MySQL gives an error on this!
No problem if the file ends with MySQL-style comments.
The problem is that phpMyAdmin removes trailing space, so it is not valid ANSI comment then:
#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 '--' at line 3
I currently don't have time to track where the space is being trimmed...
The trim occurs at 2 places:
read_dump.php, line 138 libraries/read_dump.lib.php, line 21
The bug is fixed by replacing the one at line 21 by $sql = rtrim($sql, "\n\r");
(avoid removing the last space which is necessary for ANSI-style comment)
and removing the one at line 138, however can someone tell me the purpose of the trim at line 138?
Marc
On Sat 18. 9. 2004 16:19, Marc Delisle wrote:
The trim occurs at 2 places:
Only 2? I (grep) sees 6 :-)
$ grep trim read_dump.php libraries/read_dump.lib.php sql.php | wc -l 6
read_dump.php, line 138 libraries/read_dump.lib.php, line 21
The bug is fixed by replacing the one at line 21 by $sql = rtrim($sql, "\n\r");
(avoid removing the last space which is necessary for ANSI-style comment)
and removing the one at line 138, however can someone tell me the purpose of the trim at line 138?
Well we have quite plenty trims over code and most of them are actually not necessary, maybe we could remove them and see if actually something breaks (I doubt that not trimming SQL could cause problem).
Michal C(ihar( wrote:
On Sat 18. 9. 2004 16:19, Marc Delisle wrote:
The trim occurs at 2 places:
Only 2? I (grep) sees 6 :-)
Hi Michal,
in the code flow for this problem, I see only those 2 that were executed.
$ grep trim read_dump.php libraries/read_dump.lib.php sql.php | wc -l 6
read_dump.php, line 138 libraries/read_dump.lib.php, line 21
The bug is fixed by replacing the one at line 21 by $sql = rtrim($sql, "\n\r");
(avoid removing the last space which is necessary for ANSI-style comment)
and removing the one at line 138, however can someone tell me the purpose of the trim at line 138?
Well we have quite plenty trims over code and most of them are actually not necessary, maybe we could remove them and see if actually something breaks (I doubt that not trimming SQL could cause problem).
OK I will do more tests by trimming the trim() :)
Marc