|
Tue 05 Dec 2006 09:42:31 AM UTC, comment #10:
On the other hand, as we actually only support MySQL currently, we can afford it, I guess.
|
Mon 04 Dec 2006 10:01:55 PM UTC, comment #9:
Actually Mathieu - doing a little research I wonder if this fix makes everything good for MySQL but breaks them for PostgreSQL. I think I've found some references that the latter doesn't like backtick quotes. See for example this.
|
Mon 04 Dec 2006 05:44:56 PM UTC, comment #8:
I guessed that. Thanks very much for the speedy attention, the patches you made are exactly as I did here locally.
|
Mon 04 Dec 2006 05:30:41 PM UTC, comment #7:
(Ignore my question in comment #4, comment #3 where not posted yet when I started to write comment #4)
|
Mon 04 Dec 2006 04:23:42 PM UTC, comment #6:
Ok, so now it should be fixed and I'll repackage release 3.0 because we exactly match relevant cases.
|
Mon 04 Dec 2006 04:22:50 PM UTC, SVN revision 6483:
Fix a bug causing export function to be broken with MySQL 5
(bug #7926).
(Browse SVN revision 6483) |
Mon 04 Dec 2006 04:15:59 PM UTC, comment #4:
Are you even able to plan an export?
For the same reason, on a test install running debian testing, I was not even able to plan an export.
Somehow, it seems that recent version of mysql now longer allow sql to be a field name without being escaped, so this bug occurs whenever this field named sql is involved.
I guess it has to do with MySQL 5.
|
Mon 04 Dec 2006 04:05:26 PM UTC, comment #3:
Actually, on further examination this problem occurs for me in the frontend too. Attempts to "export" from the trackers fail with a SQL Insert Error.
Examination of the query formed and testing reveals that the PHP trips up in the same place - sql as a column name with MySQL.
|
Mon 04 Dec 2006 03:02:02 PM UTC, comment #2:
This is a server installed freshly for savane, using Debian etch (which is of course a slightly moving target at the moment).
I realise that escaping stuff there is inelegant, I'm not really very fluent in Perl and didn't want to poke about too much.
From dpkg --list | grep perl, I guess the most relevant packages are
ii libdbd-mysql-perl 3.0008-1
ii libdbd-pg-perl 1.49-2
ii libdbi-perl 1.53-1
ii perl 5.8.8-6.1
ii perl-base 5.8.8-6.1
ii perl-modules 5.8.8-6.1
The problem was there when the server was initially installed (just after 2.0 release), and eventually I commented out the line in /etc/cron.d till I had more time to look at it. I did a dist-upgrade today of everything from etch and savane.
Anything else I should look at?
|
Mon 04 Dec 2006 02:52:14 PM UTC, comment #1:
What is puzzling in the fact that this did not happen on any other installation. Which debian version do you run? Which version of perl dbi is it?
(BTW, escaping stuff should be done using dbi own quote function)
|
Mon 04 Dec 2006 02:43:32 PM UTC, original submission:
On my Debian install, sv_export keeps crashing out with
DBD::mysql::st execute failed: 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 'sql, status, date, frequency_day, frequency_hour FROM trackers_export WHERE date' at line 1 at /usr/lib/perl5/Savane/DB.pm line 181.
DBD::mysql::st execute failed: 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 'sql, status, date, frequency_day, frequency_hour FROM trackers_export WHERE date' at line 1 at /usr/lib/perl5/Savane/DB.pm line 181.
After exploring the Perl, I found it was actually the sql column name giving the grief. I have enclosed it in backticks - this is a MySQL only trick though perhaps? I think it's around line 116 of sv_export: (other lines shown for context)
Seems to be working correctly now (I'm not sure, the table is empty).
|
Related Recipes:
Savane - Bugs: bug #7926, sv_export / planning export fails...