Re: [Fwd: Re: failed: ERROR OCIEnvNlsCreate. Check (everything)]
[email protected] ("m. allan noah")
| Newsgroups | perl.dbi.users |
|---|---|
| Message-ID | <[email protected]> |
You might also wish to try using Env::C. I have had some weird cases where the perl %ENV looked ok, but the 'actual' environment was different. allan On Thu, Apr 8, 2010 at 2:51 PM, Sven Miller <[email protected]> wrote: > 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 <[email protected]> wrote: >> >> >> -------- Original Message -------- >> Subject: Re: failed: ERROR OCIEnvNlsCreate. Check (everything) >> Date: Thu, 8 Apr 2010 13:09:33 -0400 >> From: Perl Diety <[email protected]> >> To: Alexander Foken <[email protected]> >> References: <[email protected]> >> <[email protected]> <[email protected]> >> >> >> >> 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 <[email protected] >> <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]> >> http://www.foken.de/alexander/ >> >> >> >> -- >> Alexander Foken >> mailto:[email protected] http://www.foken.de/alexander/ >> >> >> > -- "The truth is an offense, but not a sin"