ID: 40542
Comment by: christopher dot jones at oracle dot com
Reported By: marvin at chag dot net
Status: Suspended
Bug Type: OCI8 related
Operating System: Linux
PHP Version: 5.2.1
New Comment:
jmgonet, the "lite" version of Oracle Instant Client has reduced
language and character set support. One counter example is:
[EMAIL PROTECTED] w]$ export NLS_LANG=_SWITZERLAND.AL32UTF8
[EMAIL PROTECTED] w]$ ~/phpsrc/php5/sapi/cli/php t1.php
Warning: ociplogon(): ORA-00604: error occurred at recursive SQL
level 1
ORA-02248: invalid option for ALTER SESSION in t1.php on line 30
ORA-00604: error occurred at recursive SQL level 1
ORA-02248: invalid option for ALTER [EMAIL PROTECTED] w]$
PHP successfully connects when NLS_LANG supported components are used
e.g.
export NLS_LANG=_AMERICA.AL32UTF8
(Check the Oracle docs for supported values)
Previous Comments:
------------------------------------------------------------------------
[2007-02-23 16:27:13] [EMAIL PROTECTED]
>So maybe another env. variable tries to "alter session"?
I doubt env variables might "alter session" and even if they do, it's
not PHP problem.
Changing the status to suspended - I'm unable to reproduce it and I
believe it's something wrong with your system or the client lib.
------------------------------------------------------------------------
[2007-02-23 09:09:45] marvin at chag dot net
I tried the workaround jmgonet kindly rovided and removed all NLS_LANG
setting from environment and startup scripts of the Apache server. The
problem persists in exactly the same way as before. Adding the charset
to the OCILogon did not help either. So maybe another env. variable
tries to "alter session"?
------------------------------------------------------------------------
[2007-02-23 08:43:23] jmgonet at iware dot ch
I've found the following workaround for that problem:
- Instead of setting the NLS_LANG environment variable, you can specify
the charset while establishing the connection:
$conn=oci_connect("USER","PASSWORD","SERVER","CHARSET");
Where charset should be the one used by PHP client (not the one used by
the Oracle server). In the case of a windows system, it is
"WE8MSWIN1252" (In my PHP server, this code is specified in the
NLS_LANG registry key, but oci_connect doesn't take it as default
value). It is "WE8MSWIN1252" even if the PHP is executed as a script,
from the command line.
The CHARSET for a linux/unix system may be "WE8ISO8851P1", or at least
it seems to be usual in Europe.
------------------------------------------------------------------------
[2007-02-23 07:31:42] jmgonet at iware dot ch
I have just the same problem, executing a PHP script as a Windows'
batch. I've set the NLS_LANG environment variable to
'NLS_LANG=FRENCH_SWITZERLAND.WE8PC850'.
I'm using Oracle 10 light client.
I've found in this (http://dbforums.com/t927204.html) and other forums,
a possible explanation:
'NLS_LANG cannot be changed by alter session, NLS_LANGUAGE and
NLS_TERRITORY can.'
------------------------------------------------------------------------
[2007-02-22 07:13:19] marvin at chag dot net
Hi Tony2001,
Thank you very much for the kind offer. Unfortunately our companies
security policies does not allow such an approach. But I will happily
investigate the problem according to your requirements and send you the
debugging information & results you need to isolate the problematic
lines.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40542
--
Edit this bug report at http://bugs.php.net/?id=40542&edit=1
