Good interesting question.

Just shows what bizarre and ridiculous results you can get because of the decision not to attempt accuracy with "exact" numerics.

Try it with DECLARE @a decimal(38,33) (or decimal(38,1), for that matter)

DECLARE @b-2 decimal(38,33)

and you will get a different result.

It's quite thoroughly broken. If the calculation of scale for multiplication were sensible

[new scale = min(s1+s2,37-(p1+p2)) is the easy option, based on exactly the same scale reduction policy as was chosen for addition and subtraction] it would be less thoroughly broken and this particular query would have a different (more useful) answer.

Of course with DECLARE @a float(25) (or any legal float definition for that matter) and DECLARE @b-2 float(25) (or float(53), or anything in between) you get 12345.123456699999224, which is an error of about only 7 parts in a quadrillion, roughly 11.2 million times as accurate as the result using decimal(38,20). So for this calculation using ordinary 8 byte floats gives a vastly nore accurate result than using 17 byte "exact numerics" unless you juggle your scale very carefully. Perhaps that will make some of those who shriek "never use float - it's approximate" think again - or perhaps not. Using Float(24) (4-byte floats) for @b-2 would of course bring in a much bigger error, but anyone who expects 12 significant (ecimal) digits out of a 23 bit significand can't do simple arithmetic.

I wonder when SQL will catch up with IEEE 754-2008 and offer decimal based (instead of binary based) floating point so that we can have the flexibility and accuracy and error detection and reporting associated with IEE 754 while avoiding the input and output rounding errors caused by converting into binary-based floating point. I expect it will take a long time, as SQL standardisation is a notoriously slow and clumsy process (at least it was in the early 90s, and I would be very surprised if it's any different now).

EDIT: Oh careless me. That's the wrong formula - using that would be even worse than the present mess!