On Wed, Sep 22, 2004 at 12:06:27PM -0400, Chris Sarnowski wrote:
>
> On Sep 21, 2004, at 5:05 PM, Tim Bunce wrote:
> >
> >DBD::Oracle simply asks for the columns as strings and it's Oracle
> >itself
> >that performs the number to string conversion. DBD::Oracle gives
> >Oracle a buffer of 133 characters for NUMBER fields, so there's
> >pleanty of room to store the number.
>
> Ahh. I've been meaning to ask about this. There is one case
> where the 133 char buffer is a problem. We are storing very
> small p-values from BLAST, and they can be down in the range
> of 1E-128 to 1E-130. Now for numbers of this magnitude it's not
> very meaningful to store more than one (or maybe 2) significant
> digits anyway, but BLAST returns 6 significant digits, and we store
> them in Oracle without trouble, but when we attempt to retrieve them
> we get a 'truncation or null fetch error' (In particular, using
> DBD::Oracle 1.14 or 1.15 with a couple different versions of Oracle 9i).
The DBD::Oracle test suite does
select 1 * power(10,-130) ...
and doesn't get an error. [Though looking at it the tests that follow
aren't useful, but at least there's no 'truncation or null fetch' error.]
Can you give me an SQL statement like that above that'll trigger the problem?
> I don't know if it constitutes a DBD::Oracle bug as such.
I think a 'truncation or null fetch error' for a NUMBER does.
Tim.
