On 2008-03-14 09:50:15 +0000, [EMAIL PROTECTED] wrote: > This is more for the archives than anything as there is a workaround. > > When inserting 1234567890.123456 into a decimal(16,6) column, the value > stored > is 1234567890.123460
The value 1234567890.123456 is not exactly representable in a perl
numeric scalar (assuming 64 bit double, which is a reasonable
assumption). The nearest representable approximation is
1234567890.12345600128173828125.
However, rounding that to 6 digits after the comma is 1234567890.123456,
so I don't see a reason for the wrong rounding. It looks more like if
it's rounded to 5 digits instead of 6.
> Having a brainwave from the Time::HiRes docs,
> sprintf('%.6f', 1234567890.123456) stores the expected value.
In this case the scalar is a string instead of a number. I don't know
the internals of DBD::mysql, but I would expect that it is also passed
as a string to the server, which then stores it "as is" (converting to
the internal decimal type of course, but that's just some
bit-twiddling).
> Is this expected behaviour or should DBD::mysql automagically do the right
> thing?
I would expect rounding errors when passing numeric scalars to "decimal"
types in general, but not in this case - that should be handled
correctly (because it can).
hp
--
_ | Peter J. Holzer | If I wanted to be "academically correct",
|_|_) | Sysadmin WSR | I'd be programming in Java.
| | | [EMAIL PROTECTED] | I don't, and I'm not.
__/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users
pgpBX1xr6w7ZF.pgp
Description: PGP signature
