Discussion :

[Etienne Bar]

Excusez-moi pour ce long post.

Soit la table suivante (créée pour les besoins de la démonstration) ds une base IB 6.0 SQL 3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TABLE LFA_LIGNES_FACTURES_2 (
    LFA_PRIX FLOAT,
    LFA_TXREM FLOAT,
    LFA_PRIX_3 DOUBLE PRECISION,
    LFA_TXREM_3 DOUBLE PRECISION,
    LFA_PRIX_2 DECIMAL (9, 2),
    LFA_TXREM_2 DECIMAL (9, 2));

Renseigné avec les valeurs qui suivent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
       LFA_PRIX       LFA_TXREM     LFA_PRIX_3    LFA_TXREM_3     LFA_PRIX_2    LFA_TXREM_2
          10.00            5.40          10.00           5.40          10.00           5.40
          10.00            5.30          10.00           5.30          10.00           5.30

Que donne comme résultat le SQL qui suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT
 
  LFA_LIGNES_FACTURES_2.LFA_PRIX *
  ((100 - LFA_LIGNES_FACTURES_2.LFA_TXREM)/ 100) as reel ,
 
  LFA_LIGNES_FACTURES_2.LFA_PRIX_2 *
  ((100 - LFA_LIGNES_FACTURES_2.LFA_TXREM_2)/ 100) as typedecimal,
 
 
  LFA_LIGNES_FACTURES_2.LFA_PRIX_3 *
  ((100 - LFA_LIGNES_FACTURES_2.LFA_TXREM_3)/ 100) as doubleprecision
 
 
FROM
  LFA_LIGNES_FACTURES_2

He ben voilà :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
            REEL  TYPEDECIMAL  DOUBLEPRECISION
            9.46        9.40               9.46
            9.47        9.40               9.47

Hé ben, oui, la valeur 5.4 stockée dans un decimal 9.2 est interprété comme un entier à savoir 6.

Je n'ai pas bu, pas fumé ni absorné de substances illicites... C'est un comportement normal, ça ? Pour moi, non ...

En lisant la doc interbase, j'appends que le type décimal 9.2 est stocké comme un entier, mais de là à le considéder comme un entier (arrondi au dessus) pour les calculs, les bras m'en tombent.

Et tout mettre en Double Precision, je veux bien, mais la taille de ma base va être légèrement modifiée....

Une idée pour m'en sortir sans changer tous mes types de données en double précision ?

[Barbibulle]

Oui c'est tout à fait normal, et c'est un des pièges (inconvéniants) de décimal.

Ce qu'il faut savoir : Pour un calcul il va toujours faire en sorte que le résultat soit de type le plus 'grand' possible.
donc 100-LFA_TXREM_2 va donner un type decimal(9,2)
puis il va le diviser par 100 et là encore le résultat sera de type decimal(9,2) et donc il arrondit...

Que faire ??? ceci par exemple :

Soit calculer dans l'ordre le plus judicieux pour ne pas perdre des décimales (donc les divisions en fin) :

(LFA_LIGNES_FACTURES_2.LFA_PRIX_2 * 100 -
LFA_LIGNES_FACTURES_2.LFA_PRIX_2 * LFA_LIGNES_FACTURES_2.LFA_TXREM_2) / 100 as typedecimal2,

Oubien le forcer à utiliser un type réel pour les calculs intermédiaires :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
  LFA_LIGNES_FACTURES_2.LFA_PRIX_2 * 
  ((100 - cast(LFA_LIGNES_FACTURES_2.LFA_TXREM_2 as real))/ 100) as typedecimal3,
 
  LFA_LIGNES_FACTURES_2.LFA_PRIX_2 * 
  ((cast(100 as real) - LFA_LIGNES_FACTURES_2.LFA_TXREM_2 )/ 100) as typedecimal4,
 
  LFA_LIGNES_FACTURES_2.LFA_PRIX_2 * 
  ((100 - LFA_LIGNES_FACTURES_2.LFA_TXREM_2 )/ cast(100 as real)) as typedecimal5,

par exemple..

Bon courage !!

[Etienne Bar]

Après de plus amples recherches, je contate que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SELECT
 
  LFA_LIGNES_FACTURES_2.LFA_PRIX_2 *
  ((100.00 - LFA_LIGNES_FACTURES_2.LFA_TXREM_2)/ 100.00) as typedecimal
 
FROM
  LFA_LIGNES_FACTURES_2

me permet de sortir un resultat correct...