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

go to bug id or search bugs for

Bug #31476 oci_connect fails if NLS_LANG != default
Submitted: 2005-01-10 18:10 UTC Modified: 2005-01-12 19:32 UTC
From: msquillace at sogei dot it Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 5CVS-2005-01-10 (dev) OS: Red Hat Enterprise Linux AS 3.0
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: msquillace at sogei dot it
New email:
PHP Version: OS:

 

 [2005-01-10 18:10 UTC] msquillace at sogei dot it 
Description:
------------
We normally set NLS_LANG=ITALIAN_ITALY.WE8ISO8859P1 in the Apache startup script, mirroring the setting used on the Oracle server, and this has always worked flawlessly with PHP up to version 4.3.0, the one we still run in production.

For a new project though we installed PHP 5.0.3 with Oracle 10g (client only; the RDBMS is on another machine) and found that the only way to successfully connect to Oracle from a PHP script is to comment out the NLS_LANG export and go back to the default (American_America.something), otherwise one gets:

PHP Warning:  oci_connect(): OCISessionBegin: ORA-00604: error occurred at recursive SQL level 1
ORA-00911: invalid character in /opt/web/php/prova_oracle.php on line 2

Here is the minimal script reproducing the error (the credentials have been modified for security reasons, but we tried several with identical results):

<?php
$conn = oci_connect("user", "passwd", "db1");
?>

It may be useful to note that if any one of the arguments is invalid (wrong username and/or password, or non-existant db instance) the OCI8 extensions works as expected, reporting the correct Oracle errors; so the problem happens after the user is authenticated, when it is time to create a connection to the DB server.

Today we downloaded the 09:30 CVS snapshot of PHP 5 and upgraded the OCI8 extension, but the problem remains (this was somewhat expected, as the oci8.c diff didn't show extensive modifications).

If confirmed, I believe this is a serious bug affecting most non-English speaking PHP users.

Reproduce code:
---------------
<?php
$conn = oci_connect("user", "passwd", "db1");
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-01-10 19:23 UTC] tony2001@php.net 
I'm non-English speaking user too and I use different NLS_LANGs without any problems. 
Are you able to reproduce it with other versions of Oracle client and/or server?
 [2005-01-12 17:07 UTC] msquillace at sogei dot it 
We already tried with a 10g server and a 8i one, and could not connect (by the way, I pasted the error we got from Oracle 8i by mistake ... the one we got when calling Oracle 10g is:

PHP Warning:  oci_connect(): OCISessionBegin: ORA-00604: error occurred at recursive SQL level 1
ORA-01756: quoted string not properly terminated
 in /opt/web/php/prova1_oracle.php on line 2
)

Following your advice, we installed an Oracle 9i (9.2) client and re-run the tests, with the same results on both targets! We also installed our production PHP 4.3.0 and it gave the same problems!

To make a long story short, after two days of frustrating attempts we found that PHP isn't at fault here, but our findings may well be useful to other people.

Up until now we have been using RedHat Linux Advanced Server 2.1, and are now starting to deploy RedHat Enterprise Linux 3.0.

A seemingly slight difference between the two is that the LANG environment variable defaults to e.g. LANG=en_US on v.2.1 while on v.3.0 it defaults to LANG=en_US.UTF-8 and this is causing all the problems with the Oracle connections.

The simplest solution to the problem consists in setting LANG=en_US (as in v.2.1) e.g. in the Apache startup script, as this allows one to set the Oracle codepage freely.

Another solution is to set NLS_LANG so as not to conflict with the OS codepage setting (like when we commented out NLS_LANG, causing Oracle to default to the system setting), as in:
NLS_LANG=ITALIAN_ITALY.UTF8
NLS_LANG=ITALIAN_ITALY.AL24UTFFSS

By the way, we checked that the UTF-8 OS setting has been present since RedHat Linux 8.0 ... we simply did never install PHP and Oracle on that boxes.

A final detail worth noting is that apparently the "problem" only relates to the OCI interface, since we verified that sqlplus always works.
 [2005-01-12 19:32 UTC] tony2001@php.net 
We mark non-PHP bugs a bogus.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Mar 15 04:01:28 2025 UTC