Re: 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.

Do not rebuke them with harsh words ... but rather lead them gently - with URLs - so that they may learn wisdom.

Comment on Re: DBI converting hex values Select or Download Code

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.	[reply]
Re^3: DBI converting hex values by VSarkiss (Monsignor) on Nov 02, 2006 at 20:29 UTC
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. Do not rebuke them with harsh words ... but rather lead them gently - with URLs - so that they may learn wisdom.	[reply] [d/l] [select]
Re^3: DBI converting hex values by Fletch (Bishop) on Nov 02, 2006 at 20:24 UTC
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).	[reply] [d/l] [select]


Clear questions and runnable code get the best and fastest answer
	PerlMonks