> 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.
But tests like 22nchar_al32utf8 are failing, and only under Cygwin - these are "national" charset columns so should always be able to take Unicode (at least since 9i) - so shouldn't be skipped. Comparing two runs, cygwin vs. linux, both with: Database and client versions and character sets: Database 10.2.0.1.0 CHAR set is WE8ISO8859P15 (Non-Unicode), NCHAR set is AL16UTF16 (Unicode) Client 9.2.0.7 NLS_LANG is '.WE8ISO8859P15', NLS_NCHAR is '<unset>' http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/linux_9207full_test102_WE8ISO 8859P15_test.log t/22nchar_al32utf8......ok t/22nchar_utf8..........ok The tests run on Linux and pass. http://www.andyh.co.uk/temp/DBD-Oracle/1.17RC1/cygwin_9207full_test102_WE8IS O8859P15_test.log t/22nchar_al32utf8...... [ ... ] Failed 2/37 tests, 94.59% okay t/22nchar_utf8.......... [ ... ] Failed 6/53 tests, 88.68% okay The same tests, same database, same NLS_LANG, fail under Cygwin. Unless I'm missing something! But that's why it looks a bit more involved to fix to me? -- Andy Hassall :: [EMAIL PROTECTED] :: http://www.andyh.co.uk http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
