I've dealt with similar issues using MS SQL Server 7.0. Apparently, DBI sometimes insists upong trying a "varchar" when you want a longvarchar. I used an approach like the following to deal with this:
#!c:\perl\bin\perl.exe -w
use strict;
use DBI qw':sql_types';
my $DSN = '********';
my $USER = '********';
my $PASSWORD = '********';
# Connect to database
my $dbh = DBI->connect("dbi:ODBC:$DSN", $USER, $PASSWORD,
{RaiseError => 1})
or die "Couldn't connect to database: " . DBI->errstr;
# 0 - Trace disabled.
# 1 - Trace DBI method calls returning with results or errors.
# 2 - Trace method entry with parameters and returning with results.
# 3 - As above, adding some high-level information from the driver
# and some internal information from the DBI.
# 4 - As above, adding more detailed information from the driver.
# Also includes DBI mutex information when using threaded Perl.
# 5 and above - As above but with more and more obscure information.
DBI->trace(2, "trace.txt");
The trace statement creates a file ("trace.txt", in this case) with a trace of the DBI functions, including what variable types it's trying to bind columns to. You can read through the trace to find out if it's trying to bind the wrong type. If so, the following should work (so long as you use :sql_types):
$sth->bind_param($bind_col, $variable, SQL_LONGVARCHAR);
The sql must be prepared first, and it must be prepared with placeholders. Then, $bind_col is the number of the placeholder you wish to bind and $variable is the data to be bound to it. Also, note that the $sth->execute( $variable ); statement will still contain the variable being bound.
If you're creating some tricky SQL, consult the trace file after this method to ensure that you are binding the correct column.
Cheers,
Ovid
Join the Perlmonks Setiathome Group or just go the the link and check out our stats. |