There is more than one way of getting this error, but the most common reason is the application calling SQLBindCol
with a very large BufferLength
argument. This often arises from the following sequence of events:
SQLPrepare(select bigcol from table)
SQLExecute
SQLDescribeCol(1)
- returns bigcol, which is a big number (for example, 1073741824)SQLBindCol(1
, BufferLength=number_returned_from_SQLDescribeCol)
SQLBindCol
with a very large buffer size.In effect, the application is saying I have this much memory available for the column data (even if it doesn't). The ODBC-ODBC Bridge server needs to allocate the same buffer size to hold the data returned from the ODBC driver, and in the case of very large buffers, this is sometimes not possible. In most cases, the application did not intend to do this or does not have that much buffer space available. There is one specific example of this with Perl's DBD::ODBC driver and SQL_WLONGVARCHAR
columns.
DBD::ODBC only supports SQL_WLONGVARCHAR
if the ODBC header files it is built with include sqlucode.h
. In some versions of DBD::ODBC, sqlucode.h
is not included, and so when an SQL_WLONGVARCHAR
column is fetched, DBD::ODBC ignores LongReadLen
and uses the value from SQLDescribeCol
.
When building DBD::ODBC 0.45 or earlier with the ODBC-ODBC Bridge or unixODBC, Makefile.PL
needs to be altered to include sqlucode.h
output in dbdodbc.h
. To do this:
Makefile.PL
you need to change.Makefile.PL
that starts with:
elsif ($myodbc eq 'esodbc') {
move down the blocks of lines from there until you find print
commands writing #include
lines to SQLH
. At the end of the three print commands (but before the end of the }
block) add:
print SQLH qq{#include <sqlucode.h>\n};
-Or
Makefile.PL
starting with:
"elsif ($myodbc eq 'unixodbc') {"
Now follow the instructions in the previous bullet.
perl Makefile.PL
, you should now have a file called dbdodbc.h
, which contains a line like this:
#include <sqlucode.h>