#40542 [Sus->Bgs]: "ORA-02248: invalid option for ALTER SESSION" on OCIPLogon

ID: 40542 Updated by: tony2001@php.net Reported By: marvin at chag dot net -Status: Suspended +Status: Bogus Bug Type: OCI8 related Operating System: Linux PHP Version: 5.2.1 New Comment: . Previous Comments: ------------------------------------------------------------------------ [2007-03-02 20:56:57] christopher dot jones at oracle dot com jmgonet, the "lite" version of Oracle Instant Client has reduced language and character set support. One counter example is: [cjones@localhost w]$ export NLS_LANG=_SWITZERLAND.AL32UTF8 [cjones@localhost 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 SESSION[cjones@localhost 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) ------------------------------------------------------------------------ [2007-02-23 16:27:13] tony2001@php.net >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.' ------------------------------------------------------------------------ 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