Re: 24implicit_utf8.t fails when compiling DBD-Oracle-1.19

[Jim Ursetto]

[Apologies if this is a duplicate; my post via NNTP did not
show up here.]

I'm having the same issue with 24implicit_utf8 on HP-UX 11.11
with 32-bit Perl 5.8.8 on PA-RISC 2.0.

I tried multiple values of NLS_LANG and NLS_NCHAR, including unset.
I tried multiple versions of DBI, DBD::Oracle and the Oracle
client. I tried HP's build of 5.8.8, compiled with fairly weak
optimization. There is a post elsewhere wherein AIX exhibited this same
issue, so it doesn't seem to be confined to HP-UX.

Finally I reverted back to 5.8.7, which passed the tests.
5.6.1 also worked.

It seems that something changed in the delta between 5.8.7 and 5.8.8 which has
broken utf8 support in DBD::Oracle. Whether that triggered a bug in Perl
itself or in the DBD::Oracle module is unknown.

I would really like to get to the bottom of this so that I can use
Perl 5.8.8. Let me know if you need any further information.

| perl | DBI | DBD::Oracle | Oracle | result |
|----------+------+-------------+--------+--------|
| 5.8.8 | 1.53 | 1.19 | 9.2.0 | FAIL |
| 5.8.8 | 1.53 | 1.19 | 9.0.1 | FAIL |
| 5.8.8 | 1.53 | 1.19 | 8.1.7 | SKIP |
| 5.6.1 | 1.48 | 1.16 | 9.2.0 | OK |
| 5.8.8 | 1.53 | 1.16 | 9.0.1 | FAIL |
| 5.8.8 | 1.48 | 1.16 | 9.0.1 | FAIL |
| HP 5.8.8 | 1.50 | 1.19 | 9.2.0 | FAIL |
| HP 5.8.8 | 1.50 | 1.19 | 9.0.1 | FAIL |
| HP 5.8.7 | 1.53 | 1.19 | 9.2.0 | OK |

Jim

On Fri, 9 Mar 2007 14:01:56 -0700, "Tanner, Richard L" did write
in <0209C4B40FD8ED45A9BE395023AC0E69271C64@azph-srv-ma04>:

> I am having a problem getting DBD-Oracle-1.19 to compile. I 'googled'
> many references to the problem identical to mine but found no solutions.

> Note We have no NLS environment variables currently set prior to running
> 'make test'.

> HP-UX 11.23 with PA-RISC2.0 Chip set

> Perl 5.8.8 configured as perl README.hpux from 5.8.8 docs and
> README.hpux.txt from Oracle DBD docs
> (non-threaded, dynamic linking, -Ae, +Z -D64 -Duselargefiles ...)

> DBI 1.54
> DBD Oracle 1.19:

> When we run 'make test' for DBD-Oracle-1.19
> t/24implicit_utf8.......
> # Failed test 'byte_string test of row 4: column: nch (uft8) smiley face'
> # in t/nchar_test_lib.pl at line 341.
> # got: '38|58'
> # expected: '226|152|186'
>
> # Failed test 'nice_string test of row 4: column: nch (uft8) smiley face'
> # in t/nchar_test_lib.pl at line 344.
> # got: '&:'
> # expected: '\x{263A}'
> # row 4: DUMP(nch) =3D Typ=3D1 Len=3D4: 0,38,0,58
>
> # Failed test 'byte_string test of row 4: column: nch (uft8) smiley face'
> # in t/nchar_test_lib.pl at line 341.
> # got: '38|58'
> # expected: '226|152|186'
>
> # Failed test 'nice_string test of row 4: column: nch (uft8) smiley face'
> # in t/nchar_test_lib.pl at line 344.
> # got: '&:'
> # expected: '\x{263A}'
> # row 4: DUMP(nch) =3D Typ=3D1 Len=3D4: 0,38,0,58
> # Looks like you failed 4 tests of 74.

--
"But when I was forced to re-examine it I saw that indeed his critique of
the argument was quite accurate. There was simply a gap in the logic of the
attempted device for assuring the avoidance of self-intersections in the
embedding of a non-compact manifold of n intrinsic dimensions in an Euclidean
space of (n+1)*(n/2)*(3*n+11) dimensions." -- Prof. John Nash
j...@3e8.org / 0x43340710 / 517B C658 D2CB 260D 3E1F 5ED1 6DB3 FBB9 4334 0710

[John Scoles]

Actullly I think this was a bug in the Oracle client it has been croping up
every once and a while but only with specific client versions..

I have been working on it and plan to do a little more this week Thanks for
the leads on this.

"Jim Ursetto" <dbi-...@3e8.org> wrote in message
news:2007033016...@3e8.org...

[Jim Ursetto]

Thank you. Specifically, I had the issue with both 9.2.0.6.0 and
9.0.1.3.0. These were the only ones I tried; I don't think I have any
other versions of 9.x laying around anywhere.

I do apparently have 10.2.0.1.0, though. I will try this one.

At 11:02am on 2007 April 02, John Scoles did write:
> Actullly I think this was a bug in the Oracle client it has been croping up
> every once and a while but only with specific client versions..
>
> I have been working on it and plan to do a little more this week Thanks for
> the leads on this.

> "Jim Ursetto" <dbi-...@3e8.org> wrote in message
> news:2007033016...@3e8.org...

> > | perl | DBI | DBD::Oracle | Oracle | result |

> > |----------+------+-------------+--------+--------|
> > | 5.8.8 | 1.53 | 1.19 | 9.2.0 | FAIL |
> > | 5.8.8 | 1.53 | 1.19 | 9.0.1 | FAIL |
> > | 5.8.8 | 1.53 | 1.19 | 8.1.7 | SKIP |
> > | 5.6.1 | 1.48 | 1.16 | 9.2.0 | OK |
> > | 5.8.8 | 1.53 | 1.16 | 9.0.1 | FAIL |
> > | 5.8.8 | 1.48 | 1.16 | 9.0.1 | FAIL |
> > | HP 5.8.8 | 1.50 | 1.19 | 9.2.0 | FAIL |
> > | HP 5.8.8 | 1.50 | 1.19 | 9.0.1 | FAIL |
> > | HP 5.8.7 | 1.53 | 1.19 | 9.2.0 | OK |

--
"the visual pattern seemed to be a sort of m-dimensional lissajous curve
formed by the intersection of 'i' with the shock wave of space-time
causality." -- zarkov, "a hit of dmt 10/9/84"

[Jim Ursetto]

I can report that 10.2.0.1.0 works. I'm not sure if using 10.x is an
option for me yet, but this is good news. Hopefully we can figure out the
underlying cause on 9.x. If you need me to do any testing please let me
know.

Jim

At 11:39am on 2007 April 02, Jim Ursetto did write:
> Thank you. Specifically, I had the issue with both 9.2.0.6.0 and
> 9.0.1.3.0. These were the only ones I tried; I don't think I have any
> other versions of 9.x laying around anywhere.
>
> I do apparently have 10.2.0.1.0, though. I will try this one.

--
"With each CPU running independently at 4Mhz, it would give us
over SIX TIMES more processor power than a 6309 CoCo3."
-- http://www.axess.com/twilight/sock/cocofile/coco4.html