On Mar 6, 2017, at 5:59 PM, Gowtham
<shiningstargau...@gmail.com<mailto:shiningstargau...@gmail.com>> wrote:
Hi Ron,
I did that.
I have two scenarios here. Both the scenarios have same
($dbh,$dbname,$user,$auth,$attr) values.
Scenario 1: executed code with ORACLE_HOME set to correct value.
Scenario 2: executed code with incorrect/wrong ORACLE_HOME env variable.
- So my code returns undef in the second scenario. I'm trying to understand the
execution part inside the subroutine _login to establish the dependency of
ORACLE_HOME on DBI connection.
$ORACLE_HOME is critical to any API involving oracle; this is not a function of
_login or exclusive to DBI. If it’s set incorrectly or undef, you will always
get a failure like this.
Without more details on your particular application, it’s difficult to
determine why your script is failing, but most common is that the perl module
is executed via some sort of process spawning a new shell and the environment
in that shell is not properly set.
What you need to ensure that the environment variable $ORACLE_HOME is set in
the process that is failing; either explicitly in the perl script via
$ENV{‘ORACLE_HOME’}= 'path to oracle_home’; or by ensuring that the defaults
for the process include that variable.
In Apache you can set it via a SetEnv statement:
SetEnv ORACLE_HOME /path/to/oracle/home
Be aware that more than just ORACLE_HOME is needed, you also need to set
LD_LIBRARY_PATH at a minimum, and perhaps TNS_ADMIN , ORACLE_BASE and
ORACLE_SID.
--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group
Institutions do not have opinions, merely customs
