• Hugo Kornelis (1/5/2012)


    SQL Kiwi (1/5/2012)


    I need to look at it a bit more closely to understand fully what the script is telling me

    I didn't disect it completely, or even execute it, but based on fist glance, I think it loads a DECIMAL(38,5) with a value that uses all the 33 digits before the decimal place, then multiplies this by 1. Because SQL Server hardcodes the result to have at least 6 decimal places and at most 38 total positions, only 32 positions before the decimal remain, and that's one too short for the current value.

    Ah yes, that seems to be exactly it. So it probably won't be seen as a bug @ MSFT (just another counter-intuitive example to add to the list). No doubt people on this thread have strong views to the contrary! Thanks for the analysis.