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");
[download]

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.