First, I found out that DBI has a trace method that I can access. Adding the following line writes out trace information to the filename specified:
The first argument is the trace level (I find that anything over 3 gives too much information and I can't understand it) and the second argument is the file to write to in append mode.# These are the trace level codes # 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 As above but with more and more obscure information. DBI->trace(3, "trace.txt");
Running the trace and reading the output revealed that DBI (or DBD::ODBC, I'm not sure which) was trying to force the errant field to be a varchar, despite the field in the database being declared as the text type. On MSSQL Server 7.0, varchar is limited to 8000 characters.
The solution: change use DBI; to
Then, after I prepared the SQL, but before it's executed, I inserted the following line:use DBI qw':sql_types';
$bind_col is the column of the text field (enumeration starts at 1, not zero). $data{'terms'} was the 23,000 character variable, and SQL_LONGVARCHAR forces it to be the text type.$sth->bind_param($bind_col, $data{'terms'}, SQL_LONGVARCHAR);
Thanks to everyone for your suggestions!
Cheers,
Ovid
In reply to (Ovid) Re: DBI Problem Solved
by Ovid
in thread DBI Problem?
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |