OK, now we're getting somewhere. :-)

So the underlying database is Sybase, and you used to use Sybase::CTLib to handle some VARBINARY-ish type. If so, and if you have the option, the easiest choice may be to switch to DBD::Sybase instead of DBD::ODBC. Then a lot of the behavior should be as you expect. (The last time I used Sybase was about five years ago, so things may have changed.)

I think I understand your problem: you know how to format the columns as string or hex, you just don't know which ones should be formatted in each way. If that's the case, then you may want to look at the TYPE attribute of the statement handle (documented in DBI, usually used along with the type_info method), which will allow you to find the underlying type of each result column. It sounds like that may give you enough information to decide how to format each column. Something like this (cheesy, untested) example:

my $type_i_want = $dbh->type_info( [ SQL_whatever ] );
# 
# ...later...
#
$sth->execute(@parameters);
my @types = $sth->{TYPE};
my $row = $sth->fetch();
for (my $i = 0; $i < $sth->{NUM_OF_FIELDS}; $i++)
{
    if ($types[$i] eq $type_i_want)
    {
        printf "0x%x", $row[$i];
    }
    else
    {
        printf "%s", $row[$i];
    }
}
[download]

Hope that gets you closer.

There may be a way to get the underlying DBD layer to treat it as binary data using bind_col or bind_param (I can't remember which is for which direction; I think you want the former).