What happens if you try to connect to that same DB instance using
SQL*plus? Does your CGI have use the same tnsnames.ora file as the
command line user?
--
Ron Reidy
Lead DBA
Array BioPharma, Inc.
-Original Message-
From: Angus McIntyre [mailto:[EMAIL PROTECTED]
Sent: Friday, August 18,
Angus McIntyre wrote:
I'm using current versions of DBI and DBD::Oracle in a CGI script,
Oracle
10.2 client talking to an Oracle 9 database, RedHat Linux. The script
previously ran successfully on a similar machine with the Oracle 9
client.
I have a simple test script, in which the
On Fri, August 18, 2006 1:25 pm, Garrett, Philip \(MAN-Corporate\) wrote:
Angus McIntyre wrote:
If I call the script as a CGI script, I get ORA-01017 in
OCISessionBegin, which is the bad username or password error.
I have had this problem before. I'm not positive, but I think it was
caused
On Fri, August 18, 2006 1:21 pm, Reidy, Ron wrote:
What happens if you try to connect to that same DB instance using
SQL*plus?
sqlplus connects without problems, using the same username and password as
the script (as mentioned, the script runs fine from the command line, but
fails to connect
So, there is no private tnsnames.ora nor $TNS_ADMIN defined on the
server (or in httpd.conf) at all? I ask again, because if either of
these situations exists, that would explain the problem.
BTW - Having Apache in the same group as the oracle software might be a
gaping security hole. Just a
I think at this point, you are going to have to post some code, and
maybe throw in the output of adding:
use Data::Dumper;
warn Dumper %ENV;
in order to get much meaningful help.
The darkest places in hell are reserved for those who maintain their
neutrality in times of moral crisis.
On Fri, August 18, 2006 2:16 pm, Reidy, Ron wrote:
So, there is no private tnsnames.ora nor $TNS_ADMIN defined on the
server (or in httpd.conf) at all? I ask again, because if either of
these situations exists, that would explain the problem.
No, there's just one 'tnsnames.ora' file in use.
