I think serge was referring to the fact that my calculated number in
java was 2.2199999 and BigDecimal will keep all the extra stuff
(99999). Which it may infact fix, but I still dont understand why
this was happening....
On the first try/save things work great, it gets saved in the database
(although it gets in there as just 2.22). As long as I keep the
program up and running it works fine. When I restart the program, and
reload the same object things starting getting funky. MySQL only
stores 2.22 (at least that I can see), but for some reason Castor gets
confused when I try to save the 2.219999999 value back in there. Or
something like that.
In any case, I dont need that kind of percision and have formatted it,
we are mostly working with Concrete products here and would be lucky
to get the .22 right on the money. But this still isn't the first time
I've seen this and others may run into it.
-Nick
On 5/27/05, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 5/27/05, Serge Maslyukov <[EMAIL PROTECTED]> wrote:
>
> > work around for this using of BigDecimal instead
> > double
>
> Serge,
>
> How is this going to solve Nick's issue? He's simply assigning a
> double value of 2.2 to the variable.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL
> PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://geronimo.apache.org/
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
