Looking at the logs again it seems the picture isn't too bad... Note that the NLS_LANG=.AL32UTF8 tests pass. That's the config you ought to use.
See the Unicode section in the DBD::Oracle docs for why Oracle's "UTF8" character set is broken and AL32UTF8 should be used instead. For the NLS_LANG=.WE8ISO8859P15 case you'll see that the unicode tests are being skipped on non-cygwin platforms, so the real bug is in the code that checks if the test should be run at all. They shouldn't. Compare: http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/cygwin_10201xe_test102_WE8ISO8859P15_test.log http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/linux_10201instant_test102_WE8ISO8859P15_test.log Shouldn't be too hard to track down. If you can do it in a day or so they I'll get it into 1.17! Tim. On Thu, Jan 12, 2006 at 12:48:22AM -0000, Andy Hassall wrote: > > On Sun, Jan 01, 2006 at 11:39:17PM -0000, Andy Hassall wrote: > >> > >> Under Cygwin there are additional Unicode-related failures. > > > > Other will have to scratch that itch. > > I'd like to scratch, since I've written a Perl+Oracle tool at the office > (an Oracle schema documentation tool) that is easier to distribute to other > departments using Cygwin than ActiveState Perl because it has quite a few > module dependencies that aren't all up-to-date using ActiveState PPM. > Although the main one was DBD::Oracle itself, but it seems ActiveState have > recently started building that again with their version that also bundles > Oracle Instant Client, so ActiveState might again be a feasible option. > > I'd feel more confident with the Cygwin route if DBD::Oracle Unicode > support was 100% under Cygwin in case anyone enters non-ISO-8859-15 data > into it (which so far they haven't - but it does use NVARCHAR2 columns just > in case). However, realistically I don't think I'll have the time to look > into it for this release, since 1.17 seems pretty close to ready. > > This may be something I can try and help with for 1.18. > > At the moment I'm not quite sure at which layer to start looking - it's > apparently something specific to the Cygwin build of Perl, or a lower-level > library within Cygwin on which its Perl is based, as neither the > Windows-native nor Linux nor Solaris builds exhibit the problem. The output > data in all the failing tests is shorter than the expected result, so it > looks like something along the line is translating the data through a > character set encoding with a smaller répertoire, such as a single-byte > encoding, or it's corrupting it by trying to force it to UTF-8 and failing > in some way - but these are just guesses so far - more investigation is > clearly needed. > > -- > Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk > http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool >
