Debugging DBD::Oracle

[cLive ;-)]

So, we're migrating servers, and another dev noticed a minor bug in yasql, which I've traced back to DBD::Oracle.

What is happening is when you DESC TABLENAME is that the precision of VARCHAR2 fields are coming back as being 4 times what it should be. I've narrowed it down to an error in the values in $sth->{PRECISION}.

What I can't work out though is where this is set. I have a feeling the issue might be in DBD::Oracle::st::_prepare call, but I'm not quite sure what's going on.

Using Data::Dumper, $sth looks like an empty hashref. If that's the case though, why does $sth->{PRECISION} return an arrayref of numbers? Is the hashref call overloaded in DBI as a method or something? I've not seen that before.

For DBD::Oracle, version 1.64 appears to be working correctly, but version 1.74 is not. Oracle Version is 11.2.0.4 - this was on different machines. When run on the same machine, results were the same for both modules.

This code demonstrates the issue:

#!/usr/bin/perl
use strict;
use warnings;
use DBI;

my $dbh = DBI->connect(...connect args to oracle db...);

$dbh->do("CREATE TABLE test__table(testfield VARCHAR2(10))") 
    or die "Can't create table: $DBI::errstr";

my $sth= $dbh->prepare("SELECT * FROM test__table");

print $sth->{PRECISION}->[0].$/;

$dbh->do("DROP TABLE test__table");

When run under v1.64, output is 10. When run under v1.74, output is 40.

Thoughts? DBD::Oracle bug to report?

Edit: I've reported the bug, but still welcome insights on how the hashref call turns into a method call (I hate these magic bits of code sometimes :D)

FINAL EDIT: We worked out the issue, at last. When migrating servers, the DBAs accidentally added a new environment variable to the /oracle/#VERSION#/CLIENT.env file that set NLS_LANG to AMERICAN_AMERICA.UTF8. The database, however, is a legacy DB that uses WE8ISO8859P1. So, yasql was expecting UTF8, but the DB wasn't supplying it.

[runrig]

Possibly the same sort of problem as this column_info bug, but for statement handle attributes. Is the column varchar2 BYTE or CHAR? Probably CHAR is my guess. So yes, report the bug.

[cLive ;-)]

Thanks - have added a link to that to the ticket. Looks very similar.

[Corion]

DBI relies heavily on tied hashes for attributes. Also, most of the meat of a DBD implementation lives in the client library of the database, which is most likely a blob of C and XS code. The Perl side of the world mostly holds a pointer to the real configuration data in XS space.

[fishmonger]

I don't work with Oracle so I can't do any testing, but the first step I suggest would be to compare the documentation and source code between those versions to see if there were any changes made to that method. Depending on the result of that investigation, you might want to submit a bug report.

[cLive ;-)]

The code in the Perl module is the same. I'm guessing the issue is in the C code. Have submitted it anyway as a bug, but was curious about the dynamic hashref call. I assume something is tied in the background somewhere...