in reply to Is setting $ENV{'NLS_LANG'} deprecated?

Thanks for sharing your wisdom, Monks!

It's good to know that I'm not trying to do something deprecated - but, unfortunately, so far none of your replies has helped to disclose the secret behind the difference between Perl 5.6.1/DBI 1.40 and Perl 5.8.6/DBI 1.601 in this case:

@derby: I suppose by "OCI" you meant "Oracle::OCI". Interestingly, for both(!) of the mentioned Perl versions

$> perl -MDBD::Oracle -e 'print "$DBD::Oracle::VERSION\n"'
returns
Can't load '/.../<PERL_VERSION>/sun4-solaris/auto/DBD/Oracle/Oracle +.so' for module DBD::Oracle: ld.so.1: perl: fatal: libclntsh.so.9.0: +open failed: No such file or directory at /.../<PERL_VERSION>/sun4-so +laris/DynaLoader.pm line <LINE_NUMBER>.
and
$> perl -MOracle::OCI -e 'print "$Oracle::OCI::VERSION\n"'
returns
Can't locate Oracle/OCI.pm in @INC (@INC contains: ...)
so it seems neither of these modules is used (at least by the working duo Perl 5.6.1 and DBI 1.40) anyway. See below for a complete code example if you like.

@mje, Tux, and cmdrake: Yes, I do set NLS_LANG before connecting to the database and I tried both setting it in the environment and setting it within a BEGIN block at the beginning of my Perl script. Even replacing UTF8 by AL32UTF8 didn't help with Perl v5.8.6/DBI v1.601 (while it didn't hurt with Perl v5.6.1/DBI v1.40).

Of course, I'm happy to share my code with you in order to provide more detailed information. I'm using a csh wrapper script

#!/bin/csh # NOTE: '...' is a placeholder for one or more levels of subdirectorie +s setenv ORACLE_HOME "/.../oracle/product/920" setenv LD_LIBRARY_PATH $ORACLE_HOME/lib32:/usr/lib:/usr/ucb/lib setenv ORA_NLS33 $ORACLE_HOME/ocommon/nls/admin/data setenv NLS_LANG AMERICAN_AMERICA.AL32UTF8 setenv LD_PRELOAD /usr/lib/libthread.so.1 /.../perldbi_with_al32utf8.pl "$1"
to set some environment variables (including NLS_LANG) and to pass one single argument (the SQL statement to be executed) to the Perl script doing the DBI stuff:
#!/...path...to...desired...version...of.../perl use strict; use warnings; use DBI; # Load the DBI module ### Attributes to pass to DBI->connect() to disable automatic error ch +ecking my %attr = ( PrintError => 0, RaiseError => 0, ); ### Connect using the Oracle driver my $dbh = DBI->connect("DBI:Oracle:", "user", "password", \%attr ) or die "Can't connect to database: ", $DBI::errstr, "\n"; ### Be prepared for long fields $dbh->{LongReadLen} = 100000; ### Prepare the SQL statement for execution my $sth = $dbh->prepare( "$ARGV[0]" ) or die "Can't prepare SQL statement: ", $dbh->errstr(), "\n"; ### Execute the statement in the database $sth->execute or die "Can't execute SQL statement: ", $sth->errstr(), "\n"; ### Retrieve the returned rows of data my @row; while ( @row = $sth->fetchrow_array() ) { print @row, "\n"; } warn "Problem in fetchrow_array(): ", $sth->errstr(), "\n" if $sth->err(); $sth->finish; ### Disconnect from the database $dbh->disconnect or warn "Failed to disconnect: ", $dbh->errstr(), "\n"; exit;
The database field which contains the data I'm actually interested in is declared to be of type LONG. (Please note, that I won't be allowed to modify any part of the database setup without losing support by the software producer.)

Do you spot anything suspicious?

Best regards
Locutus

Replies are listed 'Best First'.
Re^2: Is setting $ENV{'NLS_LANG'} deprecated?
by cmdrake (Acolyte) on Dec 16, 2008 at 03:28 UTC
    Locutus, I suspect perl -MDBD::Oracle -e 'print "$DBD::Oracle::VERSION\n"' failed because your environment wasn't set. Can you try:
    #!/bin/csh # NOTE: '...' is a placeholder for one or more levels of sub setenv ORACLE_HOME "/.../oracle/product/920" setenv LD_LIBRARY_PATH $ORACLE_HOME/lib32:/usr/lib:/usr/ucb/lib setenv ORA_NLS33 $ORACLE_HOME/ocommon/nls/admin/data setenv NLS_LANG AMERICAN_AMERICA.AL32UTF8 setenv LD_PRELOAD /usr/lib/libthread.so.1 perl -MDBD::Oracle -e 'print "$DBD::Oracle::VERSION\n"'
    and give us the versions of DBD::Oracle in both environments?
      Hi cmdrake,

      first of all I'd like to apologize for letting you wait that long for a response - Christmas holidays and several new projects starting with the begin of 2009 drew off my attention and made me forget about the really interesting things, sorry!

      Indeed, printing the version of DBD::Oracle failed due to the missing environment. Thanks for the hint. And here are, finally, the results of your csh script:

      • Perl 5.6.1 uses version 1.15 of DBD::Oracle while
      • Perl 5.8.6 uses version 1.20.
      A little but significant difference?

      Best regards
      Locutus