Tester un FLOAT dans une clause WHERE

Bonjour à tous,

Ce matin ce suis tombé sur une problème assez étonnant.

Dans SQL Server 2000, je j'ai une table CLIENT qui contient un champ [N° Client] qui est aussi la clé primaire, ce champ est un float(8)

Je m'attendais à retourner un et un seul enregistrement sur la requête :

Code:

---

1 2	SELECT * FROM CLIENT WHERE ([N° Client] = 39293.6833167824)

---

Avec un point et pas une virgule

Je m'en suis sorti avec

Code:

---

1 2	SELECT * FROM CLIENT WHERE (CONVERT(FLOAT(8), [N° Client]) LIKE CONVERT(FLOAT(8), 39293.6833167824))

---

Quelqu'un saurait me dire pourquoi je dois utiliser des conversions ? et le LIKE ( le égal ne fonctionne pas) ?

Merci

C'est normal. C'est de la plus haute supidité que d'utiliser comme clef un FLOAT qui par essence est un nombre réel APPROXIMATIF !

En effet les nombres décimaux (donc de puissance 10 comme els doigts d'une main) ne peuvent être représentés exactement (donc avec une précision de chiffre après la virgule quelconque) que par une machine décimale c'est à dire ayant une représentation en base 10. Or les ordinateurs travaillent en base 2. Donc il y a approximation de calcul entre le chiffre décimal exprimé et le chiffre calculé.
De plus cette approximation dépend de l'algorithme de calcul de chaque programme. Pour les bases de données SQL l'agorithme est la norme SQL dépendant de la spécification IEEE 754.
Si votre programme client ne respecte pas cette norme (et c'est courant) alors il n'y aura pas correspondance de valeur.

Tout ceci fait partie de chose que l'on apprend au cours élémentaire d'informatique !!!

A +

:aie:

Oui, j'imagine mieux maintenant les problème que cela peut impliquer, je ne suis pas très au point sur les type de données dans SQL, d'où ma question.

Ce champ FLOAT est la date à la création de l'enregistrement, le développeur qui a commis ça devait se dire qu'il y a peu de chance de créer deux enregistrements au même moment.

Moi, je dois juste mettre à jour l'existant, et faire que tout se passe bien entre frontal Access (97!) et la base SQL Server.

Biensûr, si on me laisse tout refaire, je ne ferais pas comme ça :mrgreen: