Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: DBI converting hex values

by VSarkiss (Monsignor)
on Nov 02, 2006 at 18:22 UTC ( #581940=note: print w/replies, xml ) Need Help??

in reply to DBI converting hex values

This really boils down to two questions: what data type is the column in your database, and what are you doing to "view" it?

Your comment leads me to believe you've got an integer or some numeric type. The internal representation, including the number base, is usually invisible to the application. So whether the column contains hex, decimal, octal, or whatever base, is up to the interpretation of the application program.

In other words, what may be more relevant is how you choose to display the value. Are you doing a print? It may be as simple as switching to printf "0x%x" to see the hex representation. See printf for details.

Of course, this is all guesswork until you clarify the first two questions.

Replies are listed 'Best First'.
Re^2: DBI converting hex values
by Sprad (Hermit) on Nov 02, 2006 at 19:05 UTC
    In this particular case, the data type is a custom type derived from Binary. But my code doesn't know that, it gets queries passed in from outside. My code runs them (managing all the DB connection details) and passes back the results.

    As for how I'm seeing the value, I'm using Data::Dumper and print statements. I could convert it back to a string representation of the hex value, but only if I can know which fields got changed in this way. Since the SQL code could be pretty much anything, I'm not sure if this is possible.

    I'd like to push this burden off to the calling scripts, since they know what their SQL is. But my intermediate layer previously used another DB module (Sybase::CTLib), which returned the hex values in the way I want. I've got to make my layer behave the same way, or I'll break all the other scripts.

    A fair fight is a sign of poor planning.

      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]; } }

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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://581940]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (2)
As of 2017-09-24 02:36 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (273 votes). Check out past polls.