Discussion :

[argyronet]

Bonjour,

J'ai un petit souci de comportement.
Dans une table où un champ est de type REAL:

Si j'insére un nombre suivants:

Code :

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

1
2
3
4
 
INSERT INTO MA_TABLE VALUES ('TEST1', 256.87, '1234')
INSERT INTO MA_TABLE VALUES ('TEST2', 256.47, '1234')
INSERT INTO MA_TABLE VALUES ('TEST3', 1256.38, '1234')

J'obtiens:

Code :

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

1
2
3
4
 
TEST1	256.87	1234
TEST2	256.47	1234
TEST3	1256.38	1234

C'est parfait...

Si j'insére un nombre suivants:

Code :

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

1
2
3
4
 
INSERT INTO MA_TABLE VALUES ('TEST4', 256.11, '5678')
INSERT INTO MA_TABLE VALUES ('TEST5', 256.57, '5678')
INSERT INTO MA_TABLE VALUES ('TEST6', 1256.81, '5678')

J'obtiens:

Code :

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

1
2
3
4
 
TEST4	256.10999	5678
TEST5	256.57001	5678
TEST6	1256.8101	5678

Après diverses tentative en vain de CAST ou CONVERT, je me permet de solliciter les experts pour avoir une explication du pourquoi il me pose ces 3 ou 4, voire 5 décimales derrière mon nombre, chose que je ne veux pas.
Quelle haine peut-il y avoir contre les 11, 57, 81 etc.

Merci

Argy

[Médiat]

C'est la méthode de codage des réels qui fait cela, si tu sais qu'il n'y a que deux décimales utilise un type du genre NUMBER(6, 2) à la place de REAL

[argyronet]

Mouais...
Bon vu que je peux changer le type du champ, la solution est la suivante:
Mettre le type du champ en Numeric avec une Scale de 2.

En fait, ce que je comprenais pas, c'est pourquoi seulement certaines décimales subissaient ce forcing de précision que je ne voulais pas et que par conséquent, les calculs qui en sont issus donnaient des résultats faux.

Merci en tout cas

Argy