The Ninja K has asked for the wisdom of the Perl Monks concerning the following question:

Good afternoon all, I'm wondering how to begin trying to deal with a strange bug that occurs maybe three to four times a month w/ PERL. first, the error: 
DBD::mysql::db do failed: You have an error in your SQL syntax near ''
+ at line 1 at /usr/local/subqueue/upps_ret.pl line 103.
ERROR: update upps_ret_q set state="C", message='Merch: Succeeded,Term
+: Succeeded' where seq_n=

[download]
next the code, 
      my $st = sprintf "update upps_ret_q set state=\"%s\", message=%s
+ where seq_n=%5d",$state,$dbh->quote($msg),int($key);

[download]
now, the box details 
Red Hat Linux release 7.0 (Guinness)
Kernel 2.2.16-22 on an i686
perl 5.6.0

[download]
As I said, this problem occurs every so often, on no predictable basis that I've been able to discern. But the code runs hundreds of times a day. The input data is as expected, nothing out of wack there, and int returns 0 on undef and non-numeric input, so technically that statement should end with seq_n=0 in a better world. But it doesn't. As such, I'm starting to wonder if this is a bug in 5.6.0? If so, should I consider upgrading to 5.8.x or within the 5.6.X series? Any suggestion on where I can find a bug list for either releases? I'd like to upgrade to 5.8.x (yay unicode), but I'd also like to not run into any known bugs with our code in the 5.8.x series as this is a production box...

Replies are listed 'Best First'.
Re: Strange experiences w/ perl 5.6.0 on linux 2.2.16-22
by pg (Canon) on Dec 09, 2002 at 19:38 UTC
    My suggestion would be put some checking around your sprintf, and make sure all the values you used to form your sql statement are not undef and well-formated. Most likely it is something like this. Even if not as simple as my professional guess, my suggestion would still be a good style you want take into consideration.
[reply]

      And placeholders. Definately placeholders. You won't have to worry about quoting then because it happens automatically (or even for some cases it saves a step or two internally)

      my $sql = 'update upps_ret_q set state=?, message=? where seq_n=?';
my $sth = $dbh->prepare( $sql );
$sth->execute( $state, $msg, $key );

      [download]
      __SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

      [download]
[reply]
[d/l]
[select]
        Hmm I haven't considered parameterizing the query yet; and I will in our dev version; however, I still have a hard time swallowing that there any value I can pass to int() which will cause it to return undef.
        I guess I'll have to bump up the error checking level to try and track this down. I was hoping it was something simple since this error only decides to grace me with it's presence every couple weeks or so, yet operates fine the other 99% of the time all day.
        Tres weird.
[reply]

Back to Seekers of Perl Wisdom