topic Re: Supressing error about unset ORACLE_HOME from DBD::Oracle in Operating System - HP-UX

Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 07:37:07 GMT

After finally successfully defeating the installation beast DBD::Oracle on HP-UX 11.00 (this was a long battle),
I'm now about to set up some monitoring scripts for our Oracle dbs.
For testing purposes I created an Oracle test instance FOO.
To use more "user-friendly" Oracle TNS names (I dislike the names our DBAs chose ;-) I provided myself with a copy of a tnsnames.ora file with wee short instance names of *all* our db instances where an Oracle listener is listening for connect requests.
I put my copy of tnsnames.ora in
/usr/local/etc/oracle
The original tnsnames.ora files provided by our DBAs reside somewhere in
$ORACLE_HOME/network/admin

Please have a look at the short sample scriplet in the attachment to see how I do the connection.

I found out that I have to take care for unsetting any ORACLE_HOME environment variable, because then the original tnsnames.ora file would take precedence over mine, which would result in a failed connection.
That's why I explicitly unset ORACLE_ENV should it be set, and only set TNS_ADMIN to point to the dir with my tnsnames.ora.
Of course I have to mention that I connect with my DBD::Oracle client remotely (i.e. DB instance runs on another host).

When I run this script I successfully get connected, which means that my client uses my tnsnames.ora since an instance FOO is officially unknown.
But what still annoys me is that I cannot supress a warning/error about an unset ORACLE_HOME, which my client really doesn't need.

Here's the output from the attached script:

ORACLE_HOME environment variable not set!
connected to FOO as system successfully

Of course, I could close or redirect STDERR to get rid of the warning/error.
I also tried to set the attribute hashref's keys RaiseError and PrintError to 0.
But this doesn't help, and I wouldn't want to do this because I'd like to catch errors.

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

H.Merijn Brand (procura — Thu, 15 Aug 2002 09:13:56 GMT

I know you are using a recent perl :)

Try if changing

#!/usr/bin/perl -w

use DBI;

to

#!/usr/bin/perl

use strict;
use warnings;
use DBI;

helps. use warnings is more localized (scoped) than -w, and might just be what you want.

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

H.Merijn Brand (procura — Thu, 15 Aug 2002 09:14:20 GMT

BTW congratulations to your new hat!

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

John Palmer — Thu, 15 Aug 2002 09:26:01 GMT

Hi Ralph,

Are you sure that you have to unset ORACLE_HOME.

I thought that Oracle will look in the directory (if it's set), otherwise /etc and $ORACLE_HOME/network/admin.

I've tried it (Oracle 8.1.7) and it picks up my (private) tnsnames.ora OK.

Regards,
John

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 09:57:13 GMT

Thank you Merijn,

but I am much more happy about that I got DBD::Oracle installed finally than about the new hat ;-)

Of course, I always "use strict".
I only felt it'd be too exaggerated for just 5 lines of code.

And, I also will be using the warnings pragma.
"-w" was just left over as an old habit from my previous Perl installation.

But even with the warnings pragma the output is exactly the same.
So I guess this must be coming rather from some Oracle lib (or the inards of DBD::Oracle) than from Perl.

But never mind, this is just a cosmetic problem that I can circumvent somehow.

What upsets me more are some bugs (so it looks to me) with the debugger of Perl 5.8.0-RC3.

For instnace the command set changed a little bit.
E.g. lower case "w" now sets a watchpoint instead of the display window, but this will be regarded as a feature I suppose.
What I miss is that the => arrow which indicated your current position, doesn't seem to work.
Shell escapes also don't work in this debugger (used to work in earlier versions by "!!").
Then the pager (I exported PAGER in my environment) isn't invoked when you use "|" before a command.
I really miss this feature, which was nice when you were looking on large nested data structures.
With nested hashes, I always used
"|x \%some_hash"
in the debugger, which would give you a nice Data::Dumper like overview of the whole data structure.

Have you come accross those as well?

I haven't been playing long enough yet with Perl 5.8.0 to have stumbled over other obscurities.
So let's see what else doesn't work the way I expect it to.

But it clearly said in CPAN, from where I always download the sources, that this version is considered "development" ("if you want to be at the bleeding edge...")

stable.tar.gz still contains Perl 5.6.1 !!!

I only installed 5.8.0 because you said this would be the only version that allowed installation of DBD::Oracle on HP-UX.
Don't you think I can step back to 5.6.1?
This would make me feel more comfortable.
But right now I haven't the time to do a new Configure/make run.
I will try if DBD::Oracle cooperates with Perl 5.6.1 on HP-UX when I find time.

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 10:03:30 GMT

I thought this would be enough, to clear some uncalled for ORACLE_HOME setting:

delete $ENV{ORACLE_HOME} if exists $ENV{ORACLE_HOME};

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Jean-Luc Oudart — Thu, 15 Aug 2002 10:05:09 GMT

use the TNS_ADMIN variable.
If not set the config files are found in $ORACLE_HOME/network/admin or /etc.

Of course there is a rule of priority.

Jean-Luc

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 10:06:08 GMT

Just double checked with the POD of delete.
Here is what it says with regard to %ENV:

Deleting from $ENV{} modifies the
environment.

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

H.Merijn Brand (procura — Thu, 15 Aug 2002 10:09:56 GMT

> But it clearly said in CPAN, from where I
> always download the sources, that this
> version is considered "development" ("if
> you want to be at the bleeding edge...")
> stable.tar.gz still contains Perl 5.6.1 !!!

What is your favourite CPAN? On ftp://ftp.funet.fi/pub/languages/perl/CPAN/src/ all looks fine. What mirror is wrong? Then I can ask the responsible persons to fix it!

> I only installed 5.8.0 because you said
> this would be the only version that allowed
> installation of DBD::Oracle on HP-UX.

No, not true. Only if you depend on Unicode 5.8.0 is *needed*. And the -A trick for Oracle is not supported in 5.6.1 Configure, but you can always alter config.sh or enter it manually if you need it.

> Don't you think I can step back to 5.6.1?

No.

> This would make me feel more comfortable.

Why?

For the debugger issues, I don't use it :)
I use ptkdb (you will need Tk) from ftp://ftp.funet.fi/pub/languages/perl/CPAN/modules/by-module/Devel/Devel-ptkdb-1.108.tar.gz so I don't have to think about debugger options and commands

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 10:13:37 GMT

Jean Luc,

please have a look at the attachment.
I explicitly set $ENV{TNS_ADMIN}.
And as I said this works, because in the
$ORACLE_HOME/network/admin/tnsnames.ora
there is no "net service name" (cited from an Oracle training booklet a DBA lent me) such as FOO.
This means I wouldn't have got a connection at all if my client resorted to the "official" tnsnames.ora

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Jean-Luc Oudart — Thu, 15 Aug 2002 10:21:10 GMT

Sorry,
sometimes the screen goes to wide and I cannot see if there is an attachment.

may be a "refresh" pb.

JL

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 10:28:06 GMT

Merijn,

I looked up my Netscape bookmarks file.
There I marked "http://www.cpan.org/"

I always thought this would redirect me by some dispatcher process (most likely written in Perl?) on that server to a mirror closest to me with enough free bandwith.

I can remember that when I configured the CPAN module (on first time of its shell invocation) that I was presented with a list of some 20 German CPAN mirrors of which I selected 5.

But I don't think Netscape is consulting the CPAN module's configuration ;-)

TK for the debugger?
Ough, that meant I could do my Perl scripting only if I had an X-server running.
Too much production in my view.
I've been most happy with Perl's own debugger.
I'm one of those anachronistic guys who don't believe in fancy images and click away icons ;-)

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

H.Merijn Brand (procura — Thu, 15 Aug 2002 10:47:17 GMT

Jean-Luc, attachment is on initial message
Ralph, I'm worse. I use print and printf statements.

N/A

BTW I just don't like Oracle!

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 11:11:04 GMT

Then I guess you are like me a civil engineer (in my case Naval Architecture) who had been too long exposed to Fortran.
(I think print/write statements are the classic Fortran debugger).

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

H.Merijn Brand (procura — Thu, 15 Aug 2002 11:17:07 GMT

Only had some fortran in school. Come and discuss on https://www.beepz.com/itrc-chat/client/index.html

prints is mostly a sninnoff of my parrallel thinking and processing (no POSIX threads though)

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Ralph Grothe — Thu, 15 Aug 2002 11:32:57 GMT

Sigh,
I envy you for your parallel thinking capabilities.
My neural network only only does things sequentially (that's why I'm so slow), or at least blocks any deliberate parallel paths.
I will have a look at your chat room...

Re: Supressing error about unset ORACLE_HOME from DBD::Oracle

Brian Crabtree — Fri, 16 Aug 2002 00:14:10 GMT

Ralph,

Most likely, the reason that you are connecting is because DBD/DBI was compiled with the Oracle Home attached. I would recommend leaving the ORACLE_HOME in place, as using the TNS_ADMIN enviroment variable will suffice. The search order is as follows:

$TNS_ADMIN
/etc
$ORACLE_HOME/network/admin
$HOME/.tnsnames.ora

Provided that you are setting the TNS_ADMIN variable, it should not matter if the ORACLE_HOME is set, and you would not get this error message.

You other option, rather than building a static tnsnames.ora file, would be to build connections dynamicly with the system name, dbname, and port number.

Brian