Frustration with DBD::CSV and UPDATE

[dpmott]

I'm writing a proof-of-concept CGI script that basically implemented an event viewer page. Since the database on the server isn't ready yet, I grabbed DBD::CSV and started coding.

I got to the part where I would want to update a database entry, and I'm using placeholders in the SQL statement, like this:

      elsif ( $action eq 'Update' )
      {
         # update the event
         my @bind = (
                      $q->param( 'title' )       || '',
                      $q->param( 'description' ) || '',
                      $q->param( 'eventdate' )   || '',
                      $q->param( 'persistent' )  || '0',
                      # $id,
                    );
                    
         # Hmmm, there appears to be a bug in here somewhere...

#        my $sth = $dbh->prepare( "UPDATE tblEvents SET title=?,descri
+ption=?,eventdate=?,persistent=? where id=?" )
         my $sth = $dbh->prepare( "UPDATE tblEvents SET title=?,descri
+ption=?,eventdate=?,persistent=? where id=$id" )
                     or die "Cannot prepare: " . $dbh->errstr();
         
         $sth->execute(@bind) or die "Cannot execute: " . $sth->errstr
+();
      }

What I have there works, but I really wanted to use a placeholder for the where clause (i.e. 'where id=?'). (The code that I have commented out would implement this). However, this doesn't work -- it writes the ID to the title field, the title to the description, the description to the eventdate field, the eventdate to the persistent field, and throws out the value provided for the persistent field.

I've noted that this same behavior can be reproduced just by supplying too many parameters to the @bind array in my example (i.e. only uncomment the $id line).

If I'm misusing the DBI interface, I'd like to know. The examples in the DBI manpage show that the where clause can have a placeholder. I suspect a bug somewhere in DBD::CSV or SQL::Statement, but I have no idea where to start looking.

Does anyone have a bit of wisdom for me?

[jZed]

Sorry, this is a known bug in SQL::Statement, fixed in the SVN version, just haven't had time to CPAN it yet.

[dpmott]

Thanks for the quick response, this allows me to preserve my sanity and stop looking for the bug all at the same time :)

Update:
SQL::Statement version 1.15 works well for me. Now this is at the top of my script:

use SQL::Statement 1.15;

WOOT!