SQL Server's "Wrong" Math

Sometimes SQL queries that include numerical calculations can produce some unintended results. This week we look at why sometimes SQL Server produces "wrong" mathematical results.
Subscribe and turn on notifications to never miss a weekly video: www.youtube.co...
Check out the related blog post for all code samples:
bertwagner.com...
Follow me on Twitter:
/ bertwagner

[@CenterpointConnect]

..... Why the heck do you only have < 3k subscribers..... Your tips are awesome and are a great speaker. Keep up the great work!

[@raufasadov8521]

Great videos like others in this channel) you got a new subscriber!

[@LarnuUK]

Data type precedence doesn't really effect the first expression, all the values are an int, so there is no implicit conversion. It's only when you use 16.(0) or 16e0 that is becomes a fact when the value is a decimal/float respectively. At that point the expression returned within the parenthesis is converted "upwards" to the appropriate data type (with the highest data type precedence).

[@zanonilabuschagne7628]

Ouch, painful video to watch - the video was great, but the memories it evoked, of an insurance system I built a long time ago (before learning this lesson)...
Thanks for a great vid, Bert. As always, really entertaining and educational... Your channel is much better than MVA (IMHO) :-)

[@StoryboardLifePhoto]

Great tutorial!!! What's the code when you cast. Are you casting as decimal or INT? I've run into problems with the number of zeros when casting equations as DECIMAL or as an INT with division. Thanks.

[@shopsmartin5851]

What about numbers of precision? How does SQL Server choose how many zeroes if it’s calculating numericals with different levels?