Not PHP problem.
I'd also recommend upgrading the DB, 8i is not supported by Oracle for a long time.

Hi Tony2001, 

The only change to our systems is switching between PHP <= 5.1.1 and PHP >= 5.1.2 (today it was 5.2.1). 

The result is: for PHP <= 5.1.1 the database connections are working fine and for PHP >= 5.1.2 they are not.

So I kindly ask, wether you please can tell me what else should cause this problem, if not PHP / OCI8?
 
Sadly upgrading this databases in this special configuration is no option. PHP documentation http://de.php.net/manual/en/ref.oci8.php states that OCI8 can be used for Oracle 7 and 8 databases, though.

open again

>So I kindly ask, wether you please can tell me what else
>should cause this problem, if not PHP / OCI8?

Sure. I'd look in Oracle or in the client library.
With such an old version it's no wonder there are problems.

Though, we can try do it this way:
Please install 5.1.1 and make sure it does work fine.
Then I'll need an unprivileged ssh account on your machine to install 5.2.1, reproduce the problem and investigate it.
I'll also need Oracle connection details.

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.

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.'

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.

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"?

>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.

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)

.