Ovid has asked for the wisdom of the Perl Monks concerning the following question:

I have a script that I copied from one directory to another and modified it to handle some slightly different data, but now it doesn't work. It will allow me to upload a 4K gif, but when I try to upload a 13K jpeg, I can prepare, but not execute, the SQL. Here's a minimal test case:
sub updateFlyer { my $contentType = shift; use DBI qw(:sql_types); my ( $sql, $sth, $dbh, $mimeType, $contentImage ); # Database connection $dbh = DBI->connect("dbi:ODBC:something", 'something', 'somepass', + {RaiseError => 1}) or die DBI->errstr; # Debug stuff if (1) { DBI->trace(2, "trace.txt"); } ( $mimeType, $contentImage ) = uploadImage( $query ); $sql = "UPDATE interface..CustomContent " . "SET contentImage = ?," . " contentImageType = ? ". "WHERE contentType = ?"; $sth = $dbh->prepare( $sql ); # Gotta bind the image $sth->bind_param( 1, $contentImage, SQL_LONGVARBINARY ); $sth->execute ( $contentImage, $mimeType, $contentType ); $sth->finish; $dbh->disconnect; }
The error message is:
DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver][SQL +Server]String or binary data would be truncated. (SQL-22001) [Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been +terminated. (SQL-01000)(DBD: st_execute/SQLExecute err=-1) at D:\some +path\cgi-bin\somescript.cgi line 447.
Digging further, I ran a trace with both this script and the working original (I cannot find a significant difference in how they are written) using the same 13K jpeg. The only difference I can see is the following information buried in the trace text:
Failed upload: (size 12723/12724/0, ptype 4, otype 1) Good upload: (size 12723/12724/12723, ptype 4, otype 1)
I'm sure that zero is the source of the problem, but I have no idea what it means.

We're using NT 4.0, service pack six with IIS and MS SQL Server 7.0. The two scripts are writing to separate tables and I have verified that the field is defined the same way in both tables.

Barring anyone having seen this problem before, can you point me to where I can get information on deciphering the DBI->trace() method's output?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

Replies are listed 'Best First'.
RE: DBI Problem - binding variables
by geektron (Curate) on Oct 04, 2000 at 02:35 UTC
    hmm... looks like you're binding the variable twice. once explicitly, and another implicitly. ( calls to $sth->execute() are implicity calls to bind_params ).

    i'd suggest binding all three input params as a matter of style. ( either do 'em all, or don't do it. . . )

    and if the 'upload' seems to be failing, an extra defensive check for the values of  ( $mimeType, $contentImage ) wouldn't hurt.

    UPDATE: there might also be a limit on the DB side. try to insert a 13K JPEG directly ( but use rollback ). or check the schema and see if you can locate the maxsize ( that's on Oracle, i dunno M$ apps ).

      Problem solved.

      The IS director took off on vacation. He's also the person who maintains the database. Seems he felt that the MIME type didn't need to have more than 10 characters.

      MIME type for progressive jpegs: image/pjpeg

      This was varchar initially but apparently got changed without telling me.

      I love it when "specifications" turn into a skeet shoot.

      I also love it when I focus on what I know (the binding) is the problem that I miss the obvious. Hmm... maybe that's why I keep voting for dud politicians.

      Cheers,
      A very red-face Ovid

      binding more than once is ok, if you set the bind_type during the bind_param(), then it remembers the type when you do the execute. At least according to the DBI docs.