FileHandle messes up Oracle connection

[nolo contendere]

I had a simple script which connected to an Oracle DB, and when I
ported the subs to a larger script, I got the following error:
DBI
connect('database=FFOSD1;sid=FFOSD1;host=fosappdaldev2;port=1521','FFOSPOCDBO',...)
failed: ERROR OCIEnvNlsCreate. Check ORACLE_HOME env var, NLS
settings, permissions, etc. at ./FFOS_CmpDriver.NEW.pl line 661
bash-2.03$ echo $ORACLE_HOME
/ffosbasedir/common/oracle/iclient10_2

I copied the head of my larger script, along with the sub to connect
to Oracle and still got the error. So I pruned various pieces of code
and discovered that commenting out 'use FileHandle;' allowed my
connection to succeed.

Anyone else notice this?



The version of Perl i'm using is:
bash-2.03$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos smmk183 5.8 generic_117350-43 sun4u sparc sunw,netra-
t12 '
config_args='-Dcc=gcc -Dprefix=/ffosbasedir/common/perl'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/
include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.2.3', gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib '
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'


Characteristics of this binary (from libperl):
Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
Built under solaris
Compiled at Jun 6 2007 12:34:43
%ENV:
PERL5LIB=""
@INC:
/ffosbasedir/common/perl/lib/5.8.8/sun4-solaris
/ffosbasedir/common/perl/lib/5.8.8
/ffosbasedir/common/perl/lib/site_perl/5.8.8/sun4-solaris
/ffosbasedir/common/perl/lib/site_perl/5.8.8
/ffosbasedir/common/perl/lib/site_perl

 

[smallpond]

I had a simple script which connected to an Oracle DB, and when I
ported the subs to a larger script, I got the following error:
DBI
connect('database=FFOSD1;sid=FFOSD1;host=fosappdaldev2;port=1521','FFOSPOCDBO',...)
failed: ERROR OCIEnvNlsCreate. Check ORACLE_HOME env var, NLS
settings, permissions, etc. at ./FFOS_CmpDriver.NEW.pl line 661
bash-2.03$ echo $ORACLE_HOME
/ffosbasedir/common/oracle/iclient10_2

I copied the head of my larger script, along with the sub to connect
to Oracle and still got the error. So I pruned various pieces of code
and discovered that commenting out 'use FileHandle;' allowed my
connection to succeed.

Anyone else notice this?

The version of Perl i'm using is:
bash-2.03$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos smmk183 5.8 generic_117350-43 sun4u sparc sunw,netra-
t12 '
config_args='-Dcc=gcc -Dprefix=/ffosbasedir/common/perl'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -pipe -I/usr/local/
include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.2.3', gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib '
libpth=/usr/local/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Characteristics of this binary (from libperl):
Compile-time options: PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
Built under solaris
Compiled at Jun 6 2007 12:34:43
%ENV:
PERL5LIB=""
@INC:
/ffosbasedir/common/perl/lib/5.8.8/sun4-solaris
/ffosbasedir/common/perl/lib/5.8.8
/ffosbasedir/common/perl/lib/site_perl/5.8.8/sun4-solaris
/ffosbasedir/common/perl/lib/site_perl/5.8.8
/ffosbasedir/common/perl/lib/site_perl
.

Almost certainly due to gross negligence on the part of the
FileHandle author. Please post your short demo of the problem
with identifying ID and password information obfuscated so
they can be properly chastised.
--S

 

[Uri Guttman]

could you show the offending code?

s> Almost certainly due to gross negligence on the part of the
s> FileHandle author. Please post your short demo of the problem
s> with identifying ID and password information obfuscated so
s> they can be properly chastised.
s> --S

shows what you know. FileHandle is a deprecated wrapper around the
current IO:: classes. it shouldn't be used anymore for any reason other
than when you have to run with very old perls. so removing it is
probably a good thing for the OP. as for why it worked in one
environment and not another, it could be version issues or the oracle
code was breaking something in FileHandle that it didn't expect to see
there (assuming it was coded with IO::* modules in mind). so ripping the
'author' of FileHandle doesn't make much sense.

uri

 

[smallpond]

could you show the offending code?

s> Almost certainly due to gross negligence on the part of the
s> FileHandle author. Please post your short demo of the problem
s> with identifying ID and password information obfuscated so
s> they can be properly chastised.
s> --S

shows what you know. FileHandle is a deprecated wrapper around the
current IO:: classes. it shouldn't be used anymore for any reason other
than when you have to run with very old perls. so removing it is
probably a good thing for the OP. as for why it worked in one
environment and not another, it could be version issues or the oracle
code was breaking something in FileHandle that it didn't expect to see
there (assuming it was coded with IO::* modules in mind). so ripping the
'author' of FileHandle doesn't make much sense.

uri

Sorry, left off the sarcasm tags. My guess is OP code does
something with the standard filehandles that FileHandle
then clobbers, but won't know until we see the code.
--S

 

[nolo contendere]

#!/usr/bin/perl

use strict; use warnings;
use DBI;
use FileHandle;

my $dbh = get_dbh();

my $sql = <<"END_SQL";
--select table_name from user_tables
select * from SUPPLIER
END_SQL

my $sth = $dbh->prepare( $sql );
$sth->execute;
$sth->dump_results();

##=====
## subs
##=====

sub get_dbh {

##------------------------------------------------------------------
## Connect to Database, and return a database handle
##
## INPUTS: 1) Database SID
## 2) Database User
## 3) Database Password
##
## OUTPUTS: 1) Database Handle object
##
my $dsn = "DBI:Oracle:database=XXXX;sid=XXXX;host=XXXX;port=XXXX";

my %attr = ( RaiseError => 1, PrintError => 1, LongReadLen =>
2000 );
my $dbh = DBI->connect($dsn, 'XXXX', 'XXXX', \%attr)
or die "Unable to connect to $ENV{GPS_DBNAME}\n" .
"SQL Err: $DBI::err\nSQL Errstr: $DBI::errstr";
return $dbh;
}

##=============
This works when I comment out 'use FileHandle;'.

If I leave it in, I get:

bash-2.03$ ./oracle_test.pl
DBI
connect('database=FFOSD1;sid=FFOSD1;host=fosappdaldev2;port=1521','FFOSPOCDBO',...)
failed: ERROR OCIEnvNlsCreate. Check ORACLE_HOME env var, NLS
settings, permissions, etc. at ./oracle_test.pl line 75