RE: :Oracle - with ora10g oci.dll

The connection is correct. We use nameserver naming protocols. That is
the sqlnet name, not the sid. We don't use TNSNAMES. And I've been
connecting to this db for years in this manner and it works on other
machines with older versions of perl and the dbi.

I agree it's not a DBD or DBI error. It's a configuration error of some
sort, but since the 1.16 DBD::Oracle from ActiveState also includes the
oracle client dlls (previously, I did the oracle install separately),
then it has introduced a new element that I'm not sure how to configure.

Another user replied suggesting that I set the TNS_ADMIN env variable.

I'll look that env variable up (not familiar with that one) and set it
appropriately and see if that helps.

L=20

-----Original Message-----
From: Reidy, Ron [mailto:Ron.Reidy@arraybiopharma.com]=20
Sent: Friday, December 30, 2005 1:34 PM
To: Mitchell, Louise M; dbi-users@perl.org
Subject: RE: :Oracle - with ora10g oci.dll

This is most likely not a DBD::Oracle nor DBI error. From oerr:

$ oerr ora 12514
12514, 00000, "TNS:listener could not resolve SERVICE_NAME given in
connect descriptor"
// *Cause: The SERVICE_NAME in the CONNECT_DATA was not found in // the
listener's tables.
// *Action: Check to make sure that the SERVICE_NAME specified is
correct.
// *Comment: This error will be returned if the (database) service has
not been // registered with the listener; a database instance that is
part of this // service may need to be started or configured properly.

Looking at your code, your connection descriptor seems suspect:
irmops.prod.irm

The correct syntax is: 'dbi:Oracle:DBNAME' # DBNAME is your database
identifier.

--
Ron Reidy
Lead DBA
Array BioPharma, Inc.

-----Original Message-----
From: Mitchell, Louise M [mailto:Louise.Mitchell@pnl.gov]
Sent: Friday, December 30, 2005 12:57 PM
To: dbi-users@perl.org
Subject: DBD::Oracle - with ora10g oci.dll


Hi,

I am having some issues with the DBD::Oracle.

I'm running Perl 5.8.7 build 813 from active state on a win2k3 server.

I installed Oracle 9.2.0 client.

I then installed DBI and DBD::Oracle (1.16), which installs the oci.dll
as well as oraociei10.dll.

I can connect using sqlplus manually from the command window, but my
connection through the dbi fails with the following error:

*******************************
DBI connect('irmops.prod.irm','batchrun',...) failed: ORA-12154:
TNS:could not resolve the connect identifier specified (DBD ERROR:
OCIServerAttach) at D:\apps\test\test.pl line 9
ORA-12154: TNS:could not resolve the connect identifier specified (DBD
ERROR: OCIServerAttach) at D:\apps\test\test.pl line 10.
************************

This would indicate an sqlnet configuration error. We use nameservers,
so I have my sqlnet.ora file properly set up in my 9.2.0 installation
under the /network/admin directory.

I'm guessing that the 10i oci is not properly configured to understand
how to get to our nameservers.

I'm a little puzzled and not sure how to handle this error, since the
10g installation is really just a few files in the /perl/bin directory.

Any help is appreciated.

Thanks,
LouiseM

This electronic message transmission is a PRIVATE communication which
contains
information which may be confidential or privileged. The information is
intended=20
to be for the use of the individual or entity named above. If you are
not the=20
intended recipient, please be aware that any disclosure, copying,
distribution=20
or use of the contents of this information is prohibited. Please notify
the
sender of the delivery error by replying to this message, or notify us
by
telephone (877-633-2436, ext. 0), and then delete it from your system.

RE: :Oracle - with ora10g oci.dll

Not using tnsnames.ora?

Using Oracle Names?

You are likely running into a bug with Oracle 9.2.

There are at least 2 documented bugs for this, probably
more undocumented ones.

The workaround? Use a tnsnames.ora file.
Seriously. There is so far, no fix for it.

I've had to do this on several client machines, both
servers and users.

Your connection from sqlplus may work fine, but that
does not mean all is well. Try doing multiple tnspings
very quickly from the command line, sometime one or more
of them will fail.

A fix might be to use an 8i client.

tnsnames.ora however is sometimes a necessary evil.

A little research on MetaLink should turn up the bugs.

HTH

Jared

On Fri, 2005-12-30 at 19:56 -0800, Mitchell, Louise M wrote:
> The connection is correct. We use nameserver naming protocols. That is
> the sqlnet name, not the sid. We don't use TNSNAMES. And I've been
> connecting to this db for years in this manner and it works on other
> machines with older versions of perl and the dbi.
>
> I agree it's not a DBD or DBI error. It's a configuration error of some
> sort, but since the 1.16 DBD::Oracle from ActiveState also includes the
> oracle client dlls (previously, I did the oracle install separately),
> then it has introduced a new element that I'm not sure how to configure.
>
> Another user replied suggesting that I set the TNS_ADMIN env variable.
>
> I'll look that env variable up (not familiar with that one) and set it
> appropriately and see if that helps.
>
> L
>
> -----Original Message-----
> From: Reidy, Ron [mailto:Ron.Reidy@arraybiopharma.com]
> Sent: Friday, December 30, 2005 1:34 PM
> To: Mitchell, Louise M; dbi-users@perl.org
> Subject: RE: :Oracle - with ora10g oci.dll
>
> This is most likely not a DBD::Oracle nor DBI error. From oerr:
>
> $ oerr ora 12514
> 12514, 00000, "TNS:listener could not resolve SERVICE_NAME given in
> connect descriptor"
> // *Cause: The SERVICE_NAME in the CONNECT_DATA was not found in // the
> listener's tables.
> // *Action: Check to make sure that the SERVICE_NAME specified is
> correct.
> // *Comment: This error will be returned if the (database) service has
> not been // registered with the listener; a database instance that is
> part of this // service may need to be started or configured properly.
>
> Looking at your code, your connection descriptor seems suspect:
> irmops.prod.irm
>
> The correct syntax is: 'dbi:Oracle:DBNAME' # DBNAME is your database
> identifier.
>
> --
> Ron Reidy
> Lead DBA
> Array BioPharma, Inc.
>
> -----Original Message-----
> From: Mitchell, Louise M [mailto:Louise.Mitchell@pnl.gov]
> Sent: Friday, December 30, 2005 12:57 PM
> To: dbi-users@perl.org
> Subject: DBD::Oracle - with ora10g oci.dll
>
>
> Hi,
>
> I am having some issues with the DBD::Oracle.
>
> I'm running Perl 5.8.7 build 813 from active state on a win2k3 server.
>
> I installed Oracle 9.2.0 client.
>
> I then installed DBI and DBD::Oracle (1.16), which installs the oci.dll
> as well as oraociei10.dll.
>
> I can connect using sqlplus manually from the command window, but my
> connection through the dbi fails with the following error:
>
> *******************************
> DBI connect('irmops.prod.irm','batchrun',...) failed: ORA-12154:
> TNS:could not resolve the connect identifier specified (DBD ERROR:
> OCIServerAttach) at D:\apps\test\test.pl line 9
> ORA-12154: TNS:could not resolve the connect identifier specified (DBD
> ERROR: OCIServerAttach) at D:\apps\test\test.pl line 10.
> ************************
>
> This would indicate an sqlnet configuration error. We use nameservers,
> so I have my sqlnet.ora file properly set up in my 9.2.0 installation
> under the /network/admin directory.
>
> I'm guessing that the 10i oci is not properly configured to understand
> how to get to our nameservers.
>
> I'm a little puzzled and not sure how to handle this error, since the
> 10g installation is really just a few files in the /perl/bin directory.
>
> Any help is appreciated.
>
> Thanks,
> LouiseM
>
> This electronic message transmission is a PRIVATE communication which
> contains
> information which may be confidential or privileged. The information is
> intended
> to be for the use of the individual or entity named above. If you are
> not the
> intended recipient, please be aware that any disclosure, copying,
> distribution
> or use of the contents of this information is prohibited. Please notify
> the
> sender of the delivery error by replying to this message, or notify us
> by
> telephone (877-633-2436, ext. 0), and then delete it from your system.
>