Hi,
In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
$sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
table.
I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
table the values in $sth->{PRECISION} for varchar2's are all quadruple what
they are above. Can anyone shed any light on what might cause this? It seems
to affect all tables.
On Thu, Oct 13, 2005 at 01:15:21AM -0400, Eric Lenio wrote:
> Hi,
>
> In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
> $sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
> table.
>
> I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
> table the values in $sth->{PRECISION} for varchar2's are all quadruple what
> they are above. Can anyone shed any light on what might cause this? It seems
> to affect all tables.
Probably due to character set related changes in recent releases.
The best thing to do would be to add some tests to one of the test files
(t/*.t) that demonstrates the problem. Pick a file to change (ie t/20select.t),
copy it (t/20select.t.orig), add the new test, check it fails (make test),
then post the output of "diff -u t/20select.t.orig t/20select.t".
Please also post the two lines of client and server character set
details output by make test.
Tim.
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Oct 13, 2005 at 09:32:33AM +0100, Tim Bunce wrote:
> On Thu, Oct 13, 2005 at 01:15:21AM -0400, Eric Lenio wrote:
> > Hi,
> >
> > In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
> > $sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
> > table.
> >
> > I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
> > table the values in $sth->{PRECISION} for varchar2's are all quadruple what
> > they are above. Can anyone shed any light on what might cause this? It seems
> > to affect all tables.
>
> Probably due to character set related changes in recent releases.
>
> The best thing to do would be to add some tests to one of the test files
> (t/*.t) that demonstrates the problem. Pick a file to change (ie t/20select.t),
> copy it (t/20select.t.orig), add the new test, check it fails (make test),
> then post the output of "diff -u t/20select.t.orig t/20select.t".
>
> Please also post the two lines of client and server character set
> details output by make test.
>
> Tim.
>
Diff file is attached. Basically I added a test to check the PRECISION
of the 2nd column in the test table, which I believe is supposed to be
10.
With this new test I get this during 'make test':
t/20select..............# failed test 12 at line 109.
# failed test 24 at line 109.
# failed test 36 at line 109.
FAILED tests 12, 24, 36-38
Failed 5/35 tests, 85.71% okay
t/21nchar............... Database and client versions and character sets:
Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
FYI I have another Oracle instance on the same machine which if I use this
instance instead of the original one used above the tests all pass.
--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="20select.t.diff"
--- t/20select.t.orig Thu Oct 13 09:32:29 2005
+++ t/20select.t Thu Oct 13 09:55:25 2005
@@ -54,7 +54,7 @@
my $sz = 8;
my $tests = 2;
-my $tests_per_set = 11;
+my $tests_per_set = 12;
$tests += @test_sets * $tests_per_set;
print "1..$tests\n";
@@ -106,6 +106,7 @@
cdif($tmp->[1][1], $data1, "Len ".length($tmp->[1][1])) );
ok(0, $tmp->[2][1] =~ m/$data2/,
cdif($tmp->[2][1], $data2, "Len ".length($tmp->[2][1])) );
+ ok(0, $sth->{PRECISION}->[1] == 10);
} # end of run_select_tests
--wac7ysb48OaltWcw--
On Thu, Oct 13, 2005 at 10:03:39AM -0400, Eric Lenio wrote:
> On Thu, Oct 13, 2005 at 09:32:33AM +0100, Tim Bunce wrote:
> > On Thu, Oct 13, 2005 at 01:15:21AM -0400, Eric Lenio wrote:
> > > Hi,
> > >
> > > In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
> > > $sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
> > > table.
> > >
> > > I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
> > > table the values in $sth->{PRECISION} for varchar2's are all quadruple what
> > > they are above. Can anyone shed any light on what might cause this? It seems
> > > to affect all tables.
> >
> > Probably due to character set related changes in recent releases.
> >
> > The best thing to do would be to add some tests to one of the test files
> > (t/*.t) that demonstrates the problem. Pick a file to change (ie t/20select.t),
> > copy it (t/20select.t.orig), add the new test, check it fails (make test),
> > then post the output of "diff -u t/20select.t.orig t/20select.t".
> >
> > Please also post the two lines of client and server character set
> > details output by make test.
>
> Diff file is attached. Basically I added a test to check the PRECISION
> of the 2nd column in the test table, which I believe is supposed to be 10.
Nice and simple. Thanks.
> With this new test I get this during 'make test':
>
> t/20select..............# failed test 12 at line 109.
> # failed test 24 at line 109.
> # failed test 36 at line 109.
> FAILED tests 12, 24, 36-38
> Failed 5/35 tests, 85.71% okay
> t/21nchar............... Database and client versions and character sets:
> Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
>
> FYI I have another Oracle instance on the same machine which if I use this
> instance instead of the original one used above the tests all pass.
What client and server character set details are output by make test
for that instance?
Tim.
On Thu, Oct 13, 2005 at 05:34:15PM +0100, Tim Bunce wrote:
> On Thu, Oct 13, 2005 at 10:03:39AM -0400, Eric Lenio wrote:
> > On Thu, Oct 13, 2005 at 09:32:33AM +0100, Tim Bunce wrote:
> > > On Thu, Oct 13, 2005 at 01:15:21AM -0400, Eric Lenio wrote:
> > > > Hi,
> > > >
> > > > In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
> > > > $sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
> > > > table.
> > > >
> > > > I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
> > > > table the values in $sth->{PRECISION} for varchar2's are all quadruple what
> > > > they are above. Can anyone shed any light on what might cause this? It seems
> > > > to affect all tables.
> > >
> > > Probably due to character set related changes in recent releases.
> > >
> > > The best thing to do would be to add some tests to one of the test files
> > > (t/*.t) that demonstrates the problem. Pick a file to change (ie t/20select.t),
> > > copy it (t/20select.t.orig), add the new test, check it fails (make test),
> > > then post the output of "diff -u t/20select.t.orig t/20select.t".
> > >
> > > Please also post the two lines of client and server character set
> > > details output by make test.
> >
> > Diff file is attached. Basically I added a test to check the PRECISION
> > of the 2nd column in the test table, which I believe is supposed to be 10.
>
> Nice and simple. Thanks.
>
> > With this new test I get this during 'make test':
> >
> > t/20select..............# failed test 12 at line 109.
> > # failed test 24 at line 109.
> > # failed test 36 at line 109.
> > FAILED tests 12, 24, 36-38
> > Failed 5/35 tests, 85.71% okay
> > t/21nchar............... Database and client versions and character sets:
> > Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> >
> > FYI I have another Oracle instance on the same machine which if I use this
> > instance instead of the original one used above the tests all pass.
>
> What client and server character set details are output by make test
> for that instance?
Here is the char set details for the instance that passes the tests:
t/21nchar............... Database and client versions and character sets:
Database 9.2.0.3.0 CHAR set is WE8ISO8859P1 (Non-Unicode), NCHAR set is AL16UTF16 (Unicode)
Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
This has triggered something in my mind where one time before I had a character
set problem in Oracle and I had to re-run some SQL inside $ORACLE_HOME to fix this,
just can't quite remember. I'll search metalink.oracle.com now.
On Thu, Oct 13, 2005 at 05:34:15PM +0100, Tim Bunce wrote:
> On Thu, Oct 13, 2005 at 10:03:39AM -0400, Eric Lenio wrote:
> > On Thu, Oct 13, 2005 at 09:32:33AM +0100, Tim Bunce wrote:
> > > On Thu, Oct 13, 2005 at 01:15:21AM -0400, Eric Lenio wrote:
> > > > Hi,
> > > >
> > > > In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
> > > > $sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
> > > > table.
> > > >
> > > > I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
> > > > table the values in $sth->{PRECISION} for varchar2's are all quadruple what
> > > > they are above. Can anyone shed any light on what might cause this? It seems
> > > > to affect all tables.
> > >
> > > Probably due to character set related changes in recent releases.
> > >
> > > The best thing to do would be to add some tests to one of the test files
> > > (t/*.t) that demonstrates the problem. Pick a file to change (ie t/20select.t),
> > > copy it (t/20select.t.orig), add the new test, check it fails (make test),
> > > then post the output of "diff -u t/20select.t.orig t/20select.t".
> > >
> > > Please also post the two lines of client and server character set
> > > details output by make test.
> >
> > Diff file is attached. Basically I added a test to check the PRECISION
> > of the 2nd column in the test table, which I believe is supposed to be 10.
>
> Nice and simple. Thanks.
>
> > With this new test I get this during 'make test':
> >
> > t/20select..............# failed test 12 at line 109.
> > # failed test 24 at line 109.
> > # failed test 36 at line 109.
> > FAILED tests 12, 24, 36-38
> > Failed 5/35 tests, 85.71% okay
> > t/21nchar............... Database and client versions and character sets:
> > Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> >
> > FYI I have another Oracle instance on the same machine which if I use this
> > instance instead of the original one used above the tests all pass.
>
> What client and server character set details are output by make test
> for that instance?
>
> Tim.
>
Tim also FYI I do get the results I expect from $dbh->column_info() (in the
COLUMN_SIZE attribute)... but $sth->{PRECISION} is still returning quadrupled
numbers for character datatypes. Do you have any other suggestions for me to
look into to try to resolve this?
On Thu, Oct 13, 2005 at 05:34:15PM +0100, Tim Bunce wrote:
> On Thu, Oct 13, 2005 at 10:03:39AM -0400, Eric Lenio wrote:
> > On Thu, Oct 13, 2005 at 09:32:33AM +0100, Tim Bunce wrote:
> > > On Thu, Oct 13, 2005 at 01:15:21AM -0400, Eric Lenio wrote:
> > > > Hi,
> > > >
> > > > In perl 5.8.3, DBD::Oracle 1.14, DBI 1.47 I get expected values when I look at
> > > > $sth->{PRECISION} to retrieve the lengths of varchar2 columns for a given
> > > > table.
> > > >
> > > > I'm now testing perl 5.8.7, DBD::Oracle 1.16, and DBI 1.48 and with the same
> > > > table the values in $sth->{PRECISION} for varchar2's are all quadruple what
> > > > they are above. Can anyone shed any light on what might cause this? It seems
> > > > to affect all tables.
> > >
> > > Probably due to character set related changes in recent releases.
> > >
> > > The best thing to do would be to add some tests to one of the test files
> > > (t/*.t) that demonstrates the problem. Pick a file to change (ie t/20select.t),
> > > copy it (t/20select.t.orig), add the new test, check it fails (make test),
> > > then post the output of "diff -u t/20select.t.orig t/20select.t".
> > >
> > > Please also post the two lines of client and server character set
> > > details output by make test.
> >
> > Diff file is attached. Basically I added a test to check the PRECISION
> > of the 2nd column in the test table, which I believe is supposed to be 10.
>
> Nice and simple. Thanks.
>
> > With this new test I get this during 'make test':
> >
> > t/20select..............# failed test 12 at line 109.
> > # failed test 24 at line 109.
> > # failed test 36 at line 109.
> > FAILED tests 12, 24, 36-38
> > Failed 5/35 tests, 85.71% okay
> > t/21nchar............... Database and client versions and character sets:
> > Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> >
> > FYI I have another Oracle instance on the same machine which if I use this
> > instance instead of the original one used above the tests all pass.
>
> What client and server character set details are output by make test
> for that instance?
>
> Tim.
>
One other piece of info: the problem does not happen in DBD::Oracle 1.14
or 1.15, but does occur in 1.16.
On Thu, Oct 13, 2005 at 12:57:52PM -0400, Eric Lenio wrote:
> > > # failed test 36 at line 109.
> > > FAILED tests 12, 24, 36-38
> > > Failed 5/35 tests, 85.71% okay
> > > t/21nchar............... Database and client versions and character sets:
> > > Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> > > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> > >
> > > FYI I have another Oracle instance on the same machine which if I use this
> > > instance instead of the original one used above the tests all pass.
> >
> > What client and server character set details are output by make test
> > for that instance?
>
> Here is the char set details for the instance that passes the tests:
>
> t/21nchar............... Database and client versions and character sets:
> Database 9.2.0.3.0 CHAR set is WE8ISO8859P1 (Non-Unicode), NCHAR set is AL16UTF16 (Unicode)
> Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
Here's an off-the-top-of-my-head patch, totally untested and barely
thought about, but it seems plausible...
Index: oci8.c
============================================================ =======
--- oci8.c (revision 1086)
+++ oci8.c (working copy)
@@ -1223,9 +1223,9 @@
/* FALLTHRU */
case 96: /* CHAR */
fbh->disize = fbh->dbsize;
+ fbh->prec = fbh->disize;
if (CS_IS_UTF8(fbh->csid))
fbh->disize = fbh->dbsize * 4;
- fbh->prec = fbh->disize;
break;
case 23: /* RAW */
fbh->disize = fbh->dbsize * 2;
Let me know if the test suite runs clean with this.
Tim.
On Fri, Oct 14, 2005 at 10:09:17PM +0100, Tim Bunce wrote:
> On Thu, Oct 13, 2005 at 12:57:52PM -0400, Eric Lenio wrote:
> > > > # failed test 36 at line 109.
> > > > FAILED tests 12, 24, 36-38
> > > > Failed 5/35 tests, 85.71% okay
> > > > t/21nchar............... Database and client versions and character sets:
> > > > Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> > > > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> > > >
> > > > FYI I have another Oracle instance on the same machine which if I use this
> > > > instance instead of the original one used above the tests all pass.
> > >
> > > What client and server character set details are output by make test
> > > for that instance?
> >
> > Here is the char set details for the instance that passes the tests:
> >
> > t/21nchar............... Database and client versions and character sets:
> > Database 9.2.0.3.0 CHAR set is WE8ISO8859P1 (Non-Unicode), NCHAR set is AL16UTF16 (Unicode)
> > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
>
> Here's an off-the-top-of-my-head patch, totally untested and barely
> thought about, but it seems plausible...
>
> Index: oci8.c
> ============================================================ =======
> --- oci8.c (revision 1086)
> +++ oci8.c (working copy)
> @@ -1223,9 +1223,9 @@
> /* FALLTHRU */
> case 96: /* CHAR */
> fbh->disize = fbh->dbsize;
> + fbh->prec = fbh->disize;
> if (CS_IS_UTF8(fbh->csid))
> fbh->disize = fbh->dbsize * 4;
> - fbh->prec = fbh->disize;
> break;
> case 23: /* RAW */
> fbh->disize = fbh->dbsize * 2;
>
> Let me know if the test suite runs clean with this.
>
> Tim.
>
Tim how/where can I get revision 1086 to patch against?
On Fri, Oct 14, 2005 at 05:34:12PM -0400, Eric Lenio wrote:
> On Fri, Oct 14, 2005 at 10:09:17PM +0100, Tim Bunce wrote:
> > On Thu, Oct 13, 2005 at 12:57:52PM -0400, Eric Lenio wrote:
> > > > > # failed test 36 at line 109.
> > > > > FAILED tests 12, 24, 36-38
> > > > > Failed 5/35 tests, 85.71% okay
> > > > > t/21nchar............... Database and client versions and character sets:
> > > > > Database 9.2.0.3.0 CHAR set is AL32UTF8 (Unicode), NCHAR set is UTF8 (Unicode)
> > > > > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> > > > >
> > > > > FYI I have another Oracle instance on the same machine which if I use this
> > > > > instance instead of the original one used above the tests all pass.
> > > >
> > > > What client and server character set details are output by make test
> > > > for that instance?
> > >
> > > Here is the char set details for the instance that passes the tests:
> > >
> > > t/21nchar............... Database and client versions and character sets:
> > > Database 9.2.0.3.0 CHAR set is WE8ISO8859P1 (Non-Unicode), NCHAR set is AL16UTF16 (Unicode)
> > > Client 9.2.0.3 NLS_LANG is 'AMERICAN_AMERICA.AL32UTF8', NLS_NCHAR is '
> >
> > Here's an off-the-top-of-my-head patch, totally untested and barely
> > thought about, but it seems plausible...
> >
> > Index: oci8.c
> > ============================================================ =======
> > --- oci8.c (revision 1086)
> > +++ oci8.c (working copy)
> > @@ -1223,9 +1223,9 @@
> > /* FALLTHRU */
> > case 96: /* CHAR */
> > fbh->disize = fbh->dbsize;
> > + fbh->prec = fbh->disize;
> > if (CS_IS_UTF8(fbh->csid))
> > fbh->disize = fbh->dbsize * 4;
> > - fbh->prec = fbh->disize;
> > break;
> > case 23: /* RAW */
> > fbh->disize = fbh->dbsize * 2;
> >
> > Let me know if the test suite runs clean with this.
>
> Tim how/where can I get revision 1086 to patch against?
It should apply fine to what you have. If not, apply by hand.
Tim.
On Fri, Oct 14, 2005 at 10:09:17PM +0100, Tim Bunce wrote:
>
> Here's an off-the-top-of-my-head patch, totally untested and barely
> thought about, but it seems plausible...
>
> Index: oci8.c
> ============================================================ =======
> --- oci8.c (revision 1086)
> +++ oci8.c (working copy)
> @@ -1223,9 +1223,9 @@
> /* FALLTHRU */
> case 96: /* CHAR */
> fbh->disize = fbh->dbsize;
> + fbh->prec = fbh->disize;
> if (CS_IS_UTF8(fbh->csid))
> fbh->disize = fbh->dbsize * 4;
> - fbh->prec = fbh->disize;
> break;
> case 23: /* RAW */
> fbh->disize = fbh->dbsize * 2;
>
> Let me know if the test suite runs clean with this.
>
> Tim.
>
Tim yes the test suite does run clean, including using the additional
test I had made for t/20select.t. Do you need any further information
from me on this?
Eric.
On Sat, Oct 15, 2005 at 11:02:42PM -0400, Eric Lenio wrote:
> On Fri, Oct 14, 2005 at 10:09:17PM +0100, Tim Bunce wrote:
> >
> > Here's an off-the-top-of-my-head patch, totally untested and barely
> > thought about, but it seems plausible...
> >
> > Index: oci8.c
> > ============================================================ =======
> > --- oci8.c (revision 1086)
> > +++ oci8.c (working copy)
> > @@ -1223,9 +1223,9 @@
> > /* FALLTHRU */
> > case 96: /* CHAR */
> > fbh->disize = fbh->dbsize;
> > + fbh->prec = fbh->disize;
> > if (CS_IS_UTF8(fbh->csid))
> > fbh->disize = fbh->dbsize * 4;
> > - fbh->prec = fbh->disize;
> > break;
> > case 23: /* RAW */
> > fbh->disize = fbh->dbsize * 2;
> >
> > Let me know if the test suite runs clean with this.
>
> Tim yes the test suite does run clean, including using the additional
> test I had made for t/20select.t. Do you need any further information
> from me on this?
No, thanks, but if you've got some time I'd appreciate more patches to
extend the test suite further...
Tim.
--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Oct 17, 2005 at 05:41:20PM +0100, Tim Bunce wrote:
> On Mon, Oct 17, 2005 at 08:24:17AM -0400, Eric Lenio wrote:
> > On Mon, Oct 17, 2005 at 11:50:22AM +0100, Tim Bunce wrote:
> > > On Sat, Oct 15, 2005 at 11:02:42PM -0400, Eric Lenio wrote:
> > > > On Fri, Oct 14, 2005 at 10:09:17PM +0100, Tim Bunce wrote:
> > > > >
> > > > > Here's an off-the-top-of-my-head patch, totally untested and barely
> > > > > thought about, but it seems plausible...
> > > > >
> > > > > Index: oci8.c
> > > > > ============================================================ =======
> > > > > --- oci8.c (revision 1086)
> > > > > +++ oci8.c (working copy)
> > > > > @@ -1223,9 +1223,9 @@
> > > > > /* FALLTHRU */
> > > > > case 96: /* CHAR */
> > > > > fbh->disize = fbh->dbsize;
> > > > > + fbh->prec = fbh->disize;
> > > > > if (CS_IS_UTF8(fbh->csid))
> > > > > fbh->disize = fbh->dbsize * 4;
> > > > > - fbh->prec = fbh->disize;
> > > > > break;
> > > > > case 23: /* RAW */
> > > > > fbh->disize = fbh->dbsize * 2;
> > > > >
> > > > > Let me know if the test suite runs clean with this.
> > > >
> > > > Tim yes the test suite does run clean, including using the additional
> > > > test I had made for t/20select.t. Do you need any further information
> > > > from me on this?
> > >
> > > No, thanks, but if you've got some time I'd appreciate more patches to
> > > extend the test suite further...
> >
> > Sure thing... do you want tests around $sth->{PRECISION} in general, or tests
> > specific to this patch?
>
> Feel free to add tests for anything and everything that takes your fancy!
>
Tim, I added 3 new tests around $sth->{PRECISION} in the attached diff
file (originally from DBD::Oracle 1.16). This tests an integer column
(PRECISION of 38 in my environment), a character column (PRECISION of
10), and a date column (PRECISION of 75).
One thing I'm not sure of: are these tests valid across all OS's and
Oracle environments? If anyone can try these tests out on non-Solaris
systems (with Oracle 9.2.0.4) that would be great. Or point out the
flaws in this approach to test, and I can try to amend the patch.
Eric.
--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="20select.t.diff"
--- t/20select.t.orig Tue Oct 25 23:49:50 2005
+++ t/20select.t Wed Oct 26 09:55:01 2005
@@ -54,7 +54,7 @@
my $sz = 8;
my $tests = 2;
-my $tests_per_set = 11;
+my $tests_per_set = 14;
$tests += @test_sets * $tests_per_set;
print "1..$tests\n";
@@ -107,6 +107,13 @@
ok(0, $tmp->[2][1] =~ m/$data2/,
cdif($tmp->[2][1], $data2, "Len ".length($tmp->[2][1])) );
+ # 10/25/2005 lenio: adding tests around $sth->{PRECISION}:
+ # 1st column, an integer, should have PRECISION of 38
+ ok(0, $sth->{PRECISION}->[0] == 38);
+ # 2nd column, character type, should have PRECISION of 10
+ ok(0, $sth->{PRECISION}->[1] == 10);
+ # 3rd column, date type, should have PRECISION of 75
+ ok(0, $sth->{PRECISION}->[2] == 75);
} # end of run_select_tests
--ZGiS0Q5IWpPtfppv--
On Wed, Oct 26, 2005 at 10:06:32AM -0400, Eric Lenio wrote:
> On Mon, Oct 17, 2005 at 05:41:20PM +0100, Tim Bunce wrote:
> > >
> > > Sure thing... do you want tests around $sth->{PRECISION} in general, or tests
> > > specific to this patch?
> >
> > Feel free to add tests for anything and everything that takes your fancy!
>
> Tim, I added 3 new tests around $sth->{PRECISION} in the attached diff
> file (originally from DBD::Oracle 1.16). This tests an integer column
> (PRECISION of 38 in my environment), a character column (PRECISION of
> 10), and a date column (PRECISION of 75).
>
> One thing I'm not sure of: are these tests valid across all OS's and
> Oracle environments? If anyone can try these tests out on non-Solaris
> systems (with Oracle 9.2.0.4) that would be great. Or point out the
> flaws in this approach to test, and I can try to amend the patch.
Thanks Eric.
Tim.
> --- t/20select.t.orig Tue Oct 25 23:49:50 2005
> +++ t/20select.t Wed Oct 26 09:55:01 2005
> @@ -54,7 +54,7 @@
> my $sz = 8;
>
> my $tests = 2;
> -my $tests_per_set = 11;
> +my $tests_per_set = 14;
> $tests += @test_sets * $tests_per_set;
> print "1..$tests\n";
>
> @@ -107,6 +107,13 @@
> ok(0, $tmp->[2][1] =~ m/$data2/,
> cdif($tmp->[2][1], $data2, "Len ".length($tmp->[2][1])) );
>
> + # 10/25/2005 lenio: adding tests around $sth->{PRECISION}:
> + # 1st column, an integer, should have PRECISION of 38
> + ok(0, $sth->{PRECISION}->[0] == 38);
> + # 2nd column, character type, should have PRECISION of 10
> + ok(0, $sth->{PRECISION}->[1] == 10);
> + # 3rd column, date type, should have PRECISION of 75
> + ok(0, $sth->{PRECISION}->[2] == 75);
>
> } # end of run_select_tests
>