> In case of Actionscript double (1.9199999999999999289457264239899814128875732421875 > from the original post) it is $500 billion.
Hi Anatole, Did you note that FDS _truncates_ the actionscript double when converting to BigDecimal? The extra information is lost in FDS. So in this case, when the tax rate keyed in at the client is off by .01%, this works out to be a 10 cent mistake on a $1,000 transaction. This problem would present itself any time the user is keying in a price on the client side, trying to save the data. Imagine a user doing a price change on thousands of items, hitting save, and watching hours of work disappear... You're right - letting the DB driver do the rounding would work if we had a separate DTO for each domain object where we could put the floating point number temporarily. Since we're using EJB 3.0, which is an excellent abstract persistence layer, we are able to allow the POJO entity to become the DTO, and thus our serialization framework (Flex) must either be fixed (by Adobe) to round correctly, or extended (a new serializable type class). So for us the immediate answer is to create a serializable BigDecimal in Actionscript which can pass through the protocol layer unscathed and give exact results on the client. This not only provides a fix for the persistence problem, but also allows the client to compute things without help from the server, and display them confidently to the user, knowing that when the server performs the same calculation, it will match exactly. Best regards, Matt -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
