En effet, ces deux types de données produisent des erreurs de calculs.
Voici un petit test pour révéler cela :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | DECLARE @mon1 smallmoney, @mon2 smallmoney, @mon3 smallmoney, @mon4 smallmoney, @num1 decimal(19,4), @num2 decimal(19,4), @num3 decimal(19,4), @num4 decimal(19,4) SELECT @mon1 = 100 , @mon2 = 339 , @mon3 = 10000 --- , @num1 = 100 , @num2 = 339 , @num3 = 10000 SELECT @mon4 = @mon1 / @mon2 * @mon3 , @num4 = @num1 / @num2 * @num3 SELECT @mon4 AS money_result , @num4 AS numeric_result |
Attention donc au choix des types de données !
Money a une précision de 4 chiffres après la virgule : http://msdn.microsoft.com/en-us/library/ms179882.aspx
La première division donne 0,294985… qui, étant de type money devient 0,2949.
0,2949 * 1000 = 2949
Le compte est bon.
C’est d’ailleurs comme cela que compte les comptables. En BI, l’arrondi intermédiaire est souvent un pré-requis
Bonjour Kropernic,
Je pense que la raison est un défaut de précision qui n’est pas signalé à l’affectation et lors des calculs.
Je ne m’explique pas que cela n’ait pas été corrigé; aussi le type decimal ou numeric convient tout à fait.
Je ne trouve pas problématique que la division d’un entier par un entier produise un entier.
C’est le cas dans de nombreux autres langages; je suppose que c’est un standard
@++
Bonjour,
Merci pour l’info. Par contre, pourquoi cela produit-il ce résultat ?
Ne serait-ce pas pour le même genre de raison qu’un entier divisé par un entier donne un entier comme résultat ?