Difference like this, where cgi & perl scripts work fine, but mod_perl/ASP
doesn't, often has to do with %ENV where mod_perl is concerned.
This is because Apache clears %ENV. The best way I have found to know
what is in your %ENV for Oracle connections is to explicitly set it
before the connect like:
$ENV{'ORACLE_HOME'} = '/path/to/oracle/home';
$ENV{'NLS_LANG'} ='american_america.WE8ISO8859P1';
$ENV{'ORA_NLS33'} = $ENV{ORACLE_HOME}.'/ocommon/nls/admin/data';
DBI->connect('dbi:Oracle:' ...);
This likely has nothing to do with Apache::ASP
You can also try PerlPassEnv & PerlSetEnv for things like the
above, but explicitly setting has always given me the most mileage.
--Josh
Carl Lipo wrote:
>
> Im having an odd (and annoying) problem with text data being returned via
> Oracle::DBD (10.7) to an Apache::ASP (2.09) script. Essentially, perl that
> returns perfectly valid characters in both cgi and as a .pl file fails to
> return valid characters in the context of an Apache::ASP file. The issue,
> I think has to do with the fact that the Oracle database (8.0.6) is
> returning 8-bit characters. I can confirm this because I can repoint my
> application to a version of the database set with 7bit characters and
> everything works. While this shouldnt really be a problem (and isnt in the
> normal 'perl' setting), Apache::ASP/mod_perl seems to be barfing on these
> characters.
>
> Here's some sample code:
>
> use PNAP::Database::Query; ## a simplified database connection module
> use CGI qw/:standard/; ## for CGI output
> print header,
> start_html('A Simple Example'),
>
> ## make a database connection
> my $dbconn= new PNAP::Database::Query(Connection=>"NSPFinance", Debug=>0);
>
> ## the sql statementA
> my $orgSQL = "select o.FULLNAME";
> $orgSQL .= " from ORGANIZATION o, PARTY_ROLE pr, PARTY_ROLE_TYPE prt";
> $orgSQL .= " where o.ORGANIZATIONOID = pr.SubjectPartyOID and";
> $orgSQL .= " pr.PartyRoleTypeOID = prt.PartyRoleTypeOID and prt.ShortName =
>'NSP' and";
> $orgSQL .= " pr.StartDate <= sysdate and (pr.EndDate is null or pr.EndDate >
>sysdate)";
> $orgSQL .= " order by FULLNAME";
> my $rs = $dbconn->query(Sql=>$orgSQL, UseCursor=>0);
> if ($rs)
> {
> while ($rs->next())
> {
> my $fullname = $rs->FULLNAME; ## get the value from therecordset
> print "Fullname: ", $fullname,"<BR>\n"; ## output the value
> }
> $dbconn->finish($rs);
> }
>
> What is odd is that if I run this as a cgi (or from the command line), I
> get this output:
>
> Fullname: AT&T
> Fullname: Agis
> Fullname: At Home
> Fullname: C&W
> Fullname: CW/IDC
> Fullname: Digex
> Fullname: EBONE
> ...
>
> However, the exact same code run as an Apache::ASP page results in this
> output (on netscape for linux 4.76).
>
> Fullname:
> Fullname:
> Fullname:
> Fullname:
> Fullname:
> Fullname:
> ...
>
> On IE, however, I get this as output (viewed as source):
>
> Fullname: A T & T
> Fullname: A g i s
> Fullname: A t H o m e
> Fullname: C & W
> Fullname: C W / I D C
> Fullname: D i g e x
> Fullname: E B O N E
> ...
>
> This implies that the 8-bit characters are being rendered/dealt with
> *differently* for the cgi version and the Apache::ASP version (and that
> the Apache::ASP version honks up the 8-bit characters somehow). IE seems
> to deal with the odd characters better than netscape.
>
> In order to address this problem, Ive tried all the standard approaches to
> dealing with 8bit characters and Oracle databases (setting NLS_LANG, etc)
> and have tried using Convert::Translit module to do the conversion..
> However, none of those actions seem to make any difference. I still get
> wonky output with the mod_perl/Apache::ASP version (but not the normal
> Perl/cgi version).
>
> What I am wondering is:
>
> (1) is there a known problem with mod_perl and 8-bit character
> sets? The version of apache I am running is 1.3.19 and mod perl 1.25, and
> Apache 2.09.
>
> (2) Is there any problem with this from the Apache::ASP side in either the
> way the Response->Write is done or the way in which these character sets
> are handled? Ive looked at the Response->Write and Response->WriteRef but
> dont see anything obvious that could cause this.
>
> (3) Has anyone seen this kind of behavior before?
>
> Any help would be appreciated (it will beat having to export and re-import
> the production database)...
>
> Carl
>
> ----------------------------------------------------------------------------
> Carl Lipo EMAIL: [EMAIL PROTECTED]
> IT Systems Architect PAGER: 206.570.2086
> Internap Network Services OFFICE: 206.504.5442
> 601 Union Street, Suite 1000 FAX: 206.654.5684
> Seattle, WA 98101 CELL: 206.579.0163
>
> Unauthorized use, disclosure, or distribution of information within
> this message is prohibited.
