Depending on what it's used for, one specific entry or the whole lot, it has different endings, but the main body is 90 lines. There are 20 left joins in it.
It is an ugly thing.
So ugly, in fact, that am loath to include it here.
So ugly that I felt it necessary to comment and explain my use of joins.
This is where the trouble started.
I noticed it when I was running tests, getting the following error.
It is an ugly thing.
So ugly, in fact, that am loath to include it here.
So ugly that I felt it necessary to comment and explain my use of joins.
This is where the trouble started.
I noticed it when I was running tests, getting the following error.
Clearly, it needed a bind variable, but something along the line blocked it.
I had this problem on Friday morning on our newer server, then it stopped. Honestly, it was such a fire-fighting day that I lost track of what was happening with it.
Then the module was put on the old server and the problem rose up again.
I said "my code has gremlins" and went home at 5pm.
When I got back to the lab this morning, I made different test scripts, each identical except for the hashbang. I set one for system Perl, which is 5.10, one for the one we hardcode into most of our web and cron uses, which is 5.16, and the one we have as env perl, currently 5.20.
The cooler solution would've been to have several versions of Perl installed with Perlbrew, then running
The error occurs with 5.10. It does not with 5.16 or 5.20.
And when I run it against a version without the comments in the query, it works everywhere.
I don't have any clue if the issue is with Perl 5.10 or with the version of DBI currently installed with 5.10, and I don't expect to. The old system is a Sun machine that was off support before I was hired in, and the admin for it reminds us each time we talk to him that it's only a matter of time before it falls and can no longer get up. I haven't worked off that machine for around two years, and this query's move to the old server is part of the move of certain services to the new machine.
And, as everything is fine with Perls 5.16 or higher, I must regard this as a solved problem except with legacy installs.
I know that MySQL accepts # as the comment character, but Sublime Text prefers to make -- mean SQL comments, so when I commented the query, I used the double-dash, and our solution is to remove the comments when deploying to the old server. It's a temporary solution, to be sure, but deploying to the old server is only temporary, too.
It's a sad and strange situation where the solution is to uncomment code, but here, that seems to be it.
Update: Matt S. Trout pushed me to check into the DBD::mysql versions, to see which versions corresponded to the error. The offending 5.10 perl used DBD::mysql v. 4.013, and looking at the DBD::mysql change log, I see bug #30033: Fixed handling of comments to allow comments that contain characters that might otherwise cause placeholder detection to not work properly. Matt suggests adding "
I had this problem on Friday morning on our newer server, then it stopped. Honestly, it was such a fire-fighting day that I lost track of what was happening with it.
Then the module was put on the old server and the problem rose up again.
 |
| Whether that makes me Shatner or Lithgow remains an exercise for the reader. |
When I got back to the lab this morning, I made different test scripts, each identical except for the hashbang. I set one for system Perl, which is 5.10, one for the one we hardcode into most of our web and cron uses, which is 5.16, and the one we have as env perl, currently 5.20.
The cooler solution would've been to have several versions of Perl installed with Perlbrew, then running
perlbrew exec perl myprogram.pl instead, but I don't have Perlbrew installed on that system.The error occurs with 5.10. It does not with 5.16 or 5.20.
And when I run it against a version without the comments in the query, it works everywhere.
I don't have any clue if the issue is with Perl 5.10 or with the version of DBI currently installed with 5.10, and I don't expect to. The old system is a Sun machine that was off support before I was hired in, and the admin for it reminds us each time we talk to him that it's only a matter of time before it falls and can no longer get up. I haven't worked off that machine for around two years, and this query's move to the old server is part of the move of certain services to the new machine.
And, as everything is fine with Perls 5.16 or higher, I must regard this as a solved problem except with legacy installs.
I know that MySQL accepts # as the comment character, but Sublime Text prefers to make -- mean SQL comments, so when I commented the query, I used the double-dash, and our solution is to remove the comments when deploying to the old server. It's a temporary solution, to be sure, but deploying to the old server is only temporary, too.
It's a sad and strange situation where the solution is to uncomment code, but here, that seems to be it.
Update: Matt S. Trout pushed me to check into the DBD::mysql versions, to see which versions corresponded to the error. The offending 5.10 perl used DBD::mysql v. 4.013, and looking at the DBD::mysql change log, I see bug #30033: Fixed handling of comments to allow comments that contain characters that might otherwise cause placeholder detection to not work properly. Matt suggests adding "
use DBD::mysql 4.014;", which is more than reasonable.
No comments:
Post a Comment