On 23-5-2014 17:55, Ann Harrison wrote: > b) When your database company forces you to rewrite your application > (losing arithmetic precision in the process) for the convenience of the > company's developers, it's time to consider the cost of moving to a > different database.
I think that is a cop out. That said: I have never understood the exact problem, and from reading the old interbase manual the only real problem is that on conversion from dialect 1 to dialect 3, NUMERIC and DECIMAL with a precision larger than 9 get converted to DOUBLE PRECISION (which they technically already where!). Also - according to the Firebird Book II - division in dialect 1 is always converted to double precision, and multiplication when the precision exceeds 9 will also be converted to double precision So changing from dialect 1 to dialect 3 seems to trade the false sense of precision for actual precision. So as far as I can see the only problem might be that the current implementation does not provide enough precision (ie room) for calculations (the scale rules of multiplication and division make you run out of room quickly). If that is the actual problem, then we should solve that, not continue supporting something that was considered deprecated 15 years ago. And if that is really too much work, we should consider providing a number of UDFs (not internal functions!) that do the calculations the old way. Mark -- Mark Rotteveel ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
