Well, the problem is solved. In case anyone gets anything like this in the future, I'll detail what I did to resolve it.

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:

#  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");
[download]

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.

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

use DBI qw':sql_types';
[download]

Then, after I prepared the SQL, but before it's executed, I inserted the following line:

$sth->bind_param($bind_col, $data{'terms'}, SQL_LONGVARCHAR);
[download]

$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.

Thanks to everyone for your suggestions!

Cheers,
Ovid