> Here's another stake-in-the-ground so we know where we're at:
>
> http://www.data-plan.com/public/DBD-Oracle-1.17-RC4.tar.gz
Test results for RC4 here:
http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC4/
Just Linux and native Windows on there - all the combinations from last
time, plus new runs against an XE database (which appears to act like a
plain 10.2 database) - previously only tested the XE client, not the server.
100% pass on all of those.
For the Cygwin failures, something to do with environment variables is
prime suspect at the moment, specifically how it sets NLS_NCHAR at runtime
for some of the tests.
It seems to depend on the value of NLS_NCHAR before running the tests under
Cygwin. If it's set to AL32UTF8, then 22nchar_al32utf8 passes. If it's blank
or set to another value, the test fails. But on other platforms (even native
Windows on the same machine), the value is overridden at runtime by the
tests, so it doesn't matter what it's initially set to.
The debug output that shows the current value of NLS_NCHAR shows it as
AL32UTF8, but still it behaves as if it were the value in the parent process
environment.
There's a Perl bug "#36665: delete $ENV{FOO} leaves $FOO visible in
subprocesses on Cygwin Perl"
https://rt.perl.org/rt3/Ticket/Display.html?id=36665 which indicates there's
some issues with env vars under Cygwin Perl, but it doesn't quite explain
this behaviour - and it persisted even with trying the latest dev version of
Perl which has the fix for that particular bug.
Haven't got it quite worked out yet though, but seem to be getting closer.
--
Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
