php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #58557 sqlnet.ora doesn't seem to be read
Submitted: 2009-02-17 08:28 UTC Modified: 2009-03-11 12:08 UTC
From: ml at fatbsd dot com Assigned: sixd (profile)
Status: Closed Package: oci8 (PECL)
PHP Version: 5.2.3 OS: linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ml at fatbsd dot com
New email:
PHP Version: OS:

 

 [2009-02-17 08:28 UTC] ml at fatbsd dot com 
Description:
------------
Hello,

I used to use oci8 version 1.2.3 and I wanted to update to last version (1.3.4). Everything works fine except the fact that "sqlnet.ora" does not seems to be read.

I use the following string to describe my database in oci_connect: "MEN1PRD".

In sqlnet.ora there is the parameter NAMES.DEFAULT_DOMAIN which is set to "WORLD".

In the tnsname.ora I have a full definition for "MEN1PRD.WORLD". 

With oci8 1.2.3, it worked but since I upgraded to 1.3.4 this is not the case anymore. I have to use the same ID in oci_connect and tnsname.org. The sqlnet.ora NAMES.DEFAULT_DOMAIN does not seem to be use.

The version of php (5.2.3) is still the same, the configure options are the sames, the oracle lib is the same (9.2) and the php.ini parameters are the same too. I just changed the oci8 version.

Is this a normal behaviour ? If yes, why and is there a workaround ?

Thanks you

Reproduce code:
---------------
Piece of code which used to work (version 1.2.3) and doesn't work anymore (version 1.3.4):
$conn = oci_connect('EDUCATION', 'manager', 'MEN1PRD');

Piece of code which works (version 1.3.4):
$conn = oci_connect('EDUCATION', 'manager', 'MEN1PRD.WORLD');

Content of sqlnet.ora (which is in the same directory as tnsname.ora):
NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)
NAMES.DEFAULT_DOMAIN = WORLD
LOG_DIRECTORY_SERVER = /var/tmp

Contenat of tnsname.ora
MEN1PRD_RAC =
( DESCRIPTION =
        ( ADDRESS = ( PROTOCOL = TCP )( HOST = host1 )( PORT = 1521 ) )
        ( ADDRESS = ( PROTOCOL = TCP )( HOST = host2 )( PORT = 1521 ) )
        ( LOAD_BALANCE = yes )
        ( CONNECT_DATA =
                ( SERVER = DEDICATED )
                ( SERVICE_NAME = SN_MEN1PRD )
        )
)


Expected result:
----------------
The connexion is made to the database

Actual result:
--------------
[Mon Feb 16 18:05:14 2009] [error] [client 127.0.0.1] PHP Warning:  oci_connect() [<a href='function.oci-connect'>function.oci-connect</a>]: ORA-12154: TNS:could not resolve service name in /var/www/docs/test1.php on line 2

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-17 08:37 UTC] tony at daylessday dot org 
PHP and OCI8 do not even know such file exists - it should be read by Oracle libs.
I guess the Instant client doesn't read that file anymore, but I'm not sure.
Chris, am I right?
 [2009-02-17 10:21 UTC] ml at fatbsd dot com 
I agree with you ... php and oci8 are not aware os those files ... but as nothing change in my configuration but the oci8 version (1.2.3 to 1.3.4) I'm a little bit confused. It really seems to be oci8 related ...
 [2009-02-17 10:39 UTC] christopher dot jones at oracle dot com 
This isn't going to be a fundamental issue with the OCI8 extension. Tony is correct that the extension doesn't directly access the Oracle Network files. 

Please follow up in a support forum such as php-db@lists.php.net or Oracle's OTN PHP forum. Include information about where your network configuration files are and how you tell Apache/PHP where to find them.
 [2009-02-17 18:58 UTC] christopher dot jones at oracle dot com 
Partially reproduced. Re-opening.
 [2009-02-18 02:52 UTC] ml at fatbsd dot com 
Here is a strace of my apache running -X

http://www.fatbsd.com/oci8/strace1.txt

And here is a grep '\.ora' of this file:

     0.000226 access("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/ldap.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000187 access("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/ldap.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000160 access("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/ldap.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000124 access("/etc/intchg.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000069 access("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/intchg.ora", F_OK) = 0
     0.000091 open("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/intchg.ora", O_RDONLY) = 10
     0.000066 access("/etc/tnsnav.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000068 access("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/tnsnav.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000086 open("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/names/.sdns.ora", O_RDONLY) = -1 ENOENT (No such file or directory)
     0.000173 access("/root/.tnsnames.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000077 access("/etc/tnsnames.ora", F_OK) = -1 ENOENT (No such file or directory)
     0.000067 access("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/tnsnames.ora", F_OK) = 0
     0.000057 stat64("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/tnsnames.ora", {st_mode=S_IFREG|0644, st_size=1282, ...}) = 0
     0.000155 open("/usr/local/oracle/VERSIONS/Linux/CL.9.2.0/network/admin/tnsnames.ora", O_RDONLY) = 10

As you can see sqlnet.ora is not even tried to be accessed
 [2009-02-18 14:47 UTC] christopher dot jones at oracle dot com 
Appears to be Oracle bug 6309838 with session pooling.
 [2009-02-26 16:02 UTC] christopher dot jones at oracle dot com 
Workaround is to use Oracle 10.2.0.4 or greater.
A PHP OCI8 code work around is under investigation.
 [2009-03-09 13:06 UTC] christopher dot jones at oracle dot com 
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

Fixed in CVS.  Will be included in the (future) PECL OCI8 1.3.5 release
 [2009-03-11 12:08 UTC] christopher dot jones at oracle dot com 
Patched file is:
http://cvs.php.net/viewvc.cgi/pecl/oci8/oci8.c?r1=1.269.2.16.2.38.2.28&r2=1.269.2.16.2.38.2.29
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 12 13:01:27 2024 UTC