Description

When binary SQL data is converted to character C data, each byte
(8 bits) of source data is represented as two ASCII characters.
These characters are the ASCII character representation of the
number in its hexadecimal form. For example, a binary
00000001 is converted to
"01" and a binary 11111111
is converted to "FF".

LONGVARBINARY handling

binmode

longreadlen

result

ODBC_BINMODE_PASSTHRU

0

passthru

ODBC_BINMODE_RETURN

0

passthru

ODBC_BINMODE_CONVERT

0

passthru

ODBC_BINMODE_PASSTHRU

0

passthru

ODBC_BINMODE_PASSTHRU

>0

passthru

ODBC_BINMODE_RETURN

>0

return as is

ODBC_BINMODE_CONVERT

>0

return as char

If odbc_fetch_into() is used, passthru means that an
empty string is returned for these columns.

Parameters

result_id

The result identifier.

If result_id is 0, the
settings apply as default for new results.

Note:
Default for longreadlen is 4096 and
mode defaults to
ODBC_BINMODE_RETURN. Handling of binary long
columns is also affected by odbc_longreadlen().

Return Values

User Contributed Notes 4 notes

For Sybase users (this probably applies to MS-SQL Server as well) who are using ODBC:

I was using the same code as mizmerize, but I was getting truncated data back from the server (at the 32kb mark) when selecting data with the image datatype. My Sybase server has a @@textsize property of 2Gb, which should be plenty. But apparently, the php ODBC driver resets this to 32Kb when a connection is made, and then sets it back to 2Gb after. The solution is to do a query:

<?php odbc_exec($connH, "set textsize 131072"); ?>

immediately before your main query, in mizmerize's code. That should override the default setting.

The trick was to convert the output into hex by changing odbc_binmode to ODBC_BINMODE_CONVERT and using a handy function to convert it back to binary in order to facilitate manipulation of its size, depth etc...