NLS_LANG = en_GB.UTF-8 As I understand it, "UTF-8" is not a valid charset. It needs to be either AL32UTF8, or UTF8 (no dash). There is a difference between the two, and you probably want AL32UTF8, but I recommend researching the difference.
I know you said you tried changing this value, so this may not be the solution. Just wanted to throw it out there. On Thu, Apr 8, 2010 at 2:21 PM, Alexander Foken <alexan...@foken.de> wrote: > > > -------- Original Message -------- > Subject: Re: failed: ERROR OCIEnvNlsCreate. Check (everything) > Date: Thu, 8 Apr 2010 13:09:33 -0400 > From: Perl Diety <misterp...@gmail.com> > To: Alexander Foken <alexan...@foken.de> > References: <q2sb914e70a1004060656o63d399f3le68b76b458079...@mail.gmail.com> > <4bbc460f.5050...@easysoft.com> <4bbcf0b3.7010...@foken.de> > > > > I wrote the script to dump %ENV (in a MUCH more Perlish way than the apache > version!) but yes, you're correct; I filtered out a lot of unrelated stuff > to make the list more friendly. > > I don't think a linux apache server cares about *PATH* does it? Not sure. > The message seemed to imply PATH was only used for WINDOWS servers? > > I'm *pretty sure* our ENV VARS for the LIBs and server correctly- because > before we set them we were getting a DIFFERENT error (cant load Oracle.so). > Now we're past that error onto the next one. So I think the ORACLE_HOME and > LD paths are OK now. > > Its a preplexing problem with LOTS and LOTS of difffernt proposed fixes in > the forums. I suspect that's because there are so many possible problems. > > As a programmer, I'm not dazzled by the error message. I would never present > my users with a message like "it might be A, or possibly B, or something to > do with C, or possibly SOMETHING ELSE".. > > Instead I would CHECK A, report an A error if found,. Check B, report a B > error if found. And so on. Its unreasonable to expect a user to react to a > message that basically says IT COULD BE ANYTHING! > > In this case, some users say check the locale, language settings, others say > check LIB PATH. Others say its a DBI or DBD / Oracle version mismatch. SOme > say its an Oracle 10 security issue and I need to run an Oracle script to > un-harden it? > > I've encountered very few times in my 20 years as a programmer where ONE > error could be caused by so many possibilities. After like 4 man-weeks, > we're still fumbling with it. > > Thanks! > MP > > > > > On Wed, Apr 7, 2010 at 4:53 PM, Alexander Foken <alexan...@foken.de > <mailto:alexan...@foken.de>> wrote: > > On 07.04.2010 10:45, Martin Evans wrote: > > Perl Diety wrote: > > ENV VARS > > DOCUMENT_ROOT = /var2/www/html > GATEWAY_INTERFACE = CGI/1.1 > HTTP_ACCEPT = */* > HTTP_ACCEPT_ENCODING = gzip, deflate > HTTP_ACCEPT_LANGUAGE = en-us > HTTP_HOST = ournode.com <http://ournode.com> > HTTP_UA_CPU = x86 > HTTP_USER_AGENT = Mozilla/4.0 > LD_LIBRARY_PATH = /export/apps/oracle/product/10201/lib > LD_RUN_PATH = /export/apps/oracle/product/10201/lib > NLS_LANG = en_GB.UTF-8 > ORACLE_BASE = /export/apps/oracle > ORACLE_HOME = /export/apps/oracle/product/10201 > ORA_NLS10 = /export/apps/oracle/product/10201/nls/data/ > REQUEST_METHOD = GET > REQUEST_URI = /cgi-bin/oratest.cgi > SERVER_PORT = 80 > SERVER_PROTOCOL = HTTP/1.1 > SERVER_SIGNATURE = > > Apache/2.0.52 (Red Hat) Server at ournode.com > <http://ournode.com> Port 80 > > SERVER_SOFTWARE = Apache/2.0.52 (Red Hat) > DBI connect(...) failed: ERROR OCIEnvNlsCreate. Check > ORACLE_HOME (Linux) > env var or PATH (Windows) and or NLS settings, permissions, > etc. at > /cgi-bin/oratest.cgi line 32 > > > This looks roughly like a CGI enviromnent, and the Oracle Variables > seem to be set. But lots of variables seem to be missing, like PATH > and some variabes starting with HTTP_, SERVER_, SCRIPT_, and > REQUEST_. And the LD_xxx variables shouldn't be there. > > If this is the *complete* environment provided to the CGI, something > is *very* wrong with the Apache. > > If not, post a complete dump of %ENV in CGI context, e.g. with the > printenv script that came with Apache: > > #!/usr/local/bin/perl > ## > ## printenv -- demo CGI program which just prints its environment > ## > > print "Content-type: text/plain; charset=iso-8859-1\n\n"; > foreach $var (sort(keys(%ENV))) { > $val = $ENV{$var}; > $val =~ s|\n|\\n|g; > $val =~ s|"|\\"|g; > print "${var}=\"${val}\"\n"; > > } > > > > Did you really set AND export ORACLE_HOME or LD_LIBRARY_PATH > such that > Apache children see them? I can't remember what the syntax in the > httpd.conf file is now (SetEnv perhaps) as I no longer use > Apache but > you used to have to explicitly tell Apache which env vars to allow. > > Martin > > Two ways: > > 1. PassEnv VariableName [...] -- see > <http://httpd.apache.org/docs/2.2/mod/mod_env.html#passenv> > 2. SetEnv VariableName Value -- see > <http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv> > > I prefer PassEnv over SetEnv when the variables already exist in the > environment of the process invoking the Apache server. That way, I > don't have to change the Apache configuration when an environment > variable changes. I use SetEnv only to set additional variables that > must not appear in the environment of the process invoking the > Apache server. > > See also > > <http://alexander-foken.de/Censored%20copy%20of%20Oracle%20Troubleshooter%20HOWTO.html> > > Alexander > > -- Alexander Foken > mailto:alexan...@foken.de <mailto:alexan...@foken.de> > http://www.foken.de/alexander/ > > > > -- > Alexander Foken > mailto:alexan...@foken.de http://www.foken.de/alexander/ > > >
