Well, it does suggest a workaround that would work for SOME cases. It depends on why you're rounding, basically. Let's say that the 70.145 is US Dollars. Maybe this is an accounting program calculating interest that will be charged, but we can only charge down to the penny. So you round it, run into binary floating point issues, and it rounds incorrectly.
In one sense, the problem is fundamental and unsolvable. QlikView simply can't do this because binary floating point simply can't handle decimal arithmetic (even if it usually approximates it quite well).
But in another sense, the problem IS solvable. QlikView CAN handle INTEGER arithmetic, because binary floating point can handle integer arithmetic. So the trick is to convert all of your amounts into integers. So in this case, you could store your data not in dollars, but in tenths of a penny. So you'd store the number 70.145 as 70145 in the QlikView table, and ONLY divide by a thousand for display purposes. So you'd round(70145,10), and you should get 70150. Divide by 1000 for display at the last possible moment, and you're set.
Note also that if you do this, you must multiply by 1000 OUTSIDE of QlikView. Once QlikView gets its hands on something, the damage may already be done. So you might multiply by 1000 in the SQL, for instance.
This won't solve all possible binary vs. decimal mathematical issues, of course. But I think it can solve a common class of them, even if it's a little ugly to implement. I should mention that I've not tried this workaround in any REAL application. In our case, we simply don't need that level of accuracy, so it's OK, if we get occasional rounding errors. So while the workaround makes sense to me on the surface, I wouldn't say that it's been proved to work to solve actual company problems.
