Discussion :

[Finndelle74]

Bonjour à tous,

J'ai une table avec des salaires, qui ont au maximum 2 décimales après la virgule, que j'ai mis en réel double.
Je les affiche dans un sous-formulaire continu dans un formulaire où on peut sélectionner le salarié par une liste déroulante.
Le format du montant dans le sous-formulaire est "Euro".
Visuellement c'est bon, j'ai bien un affichage avec 2 chiffres après la virgule. Mais si l'utilisateur clique sur la ligne, plein de décimales apparaissent !

par exemple : "2 132,81 €" devient "2132,81005859375" ce qui n'est pas beau du tout... et quid de ces mystérieuses décimales ?

J'ai pris connaissance d'une discussion similaire :
https://www.developpez.net/forums/d1...males-requete/

Mais le round(salaire,2) ne fait que de changer visuellement (j'ai testé avec 0 par ex), mais pas quand on clique sur la ligne. Et quand je mets mon champ en type Décimal, je perds mes décimales dans ma table !
Je suis donc perdue sur la marche à suivre...

Merci par avance pour votre aide !

[marot_r]

Bonjour.

quid de ces mystérieuses décimales ?

Les ordinateurs (et ceux quel qu'ils soient) ne sont pas capable comme l'esprit humain de gérer une suite de décimales infinies nécessaire pour les réels.
De plus ils sont limités par la conception interne des circuits mémoires.
Et ils stockent donc une bonne approximation du nombre que tu leur donne.

Je suis donc perdue sur la marche à suivre...

Pour le type "Décimale" c'est la propriété Échelle qui détermine le nombre de décimales.
ex : si tu as une précision de 18 et une échelle de 2, tu vas pouvoir stocker un nombre avec 16 chiffres avant la virgule et 2 chiffres après soit au total 18 chiffres.
Si tu choisis une échelle de 4, tu as 14 chiffres avant la virgule et 4 après, toujours pour le même nombre total de chiffre.
Je pense que cela va répondre à ton besoin.

En passant Échelle est la traduction de "scale" mot anglais qui ne provoque pas la confusion avec l'outil de chantier.
Cela se rapporte à la notion de multiplication comme dans "l'échelle d'une carte routière" ou "économies d'échelle".

Une autre solution mais plus pénible est de stocker le nombre sous forme d'entier donc 123,45 devient 12345.
Il faut en tenir compte lors des calculs et à l'affichage 'insérer' la virgule pour que l'humain s'y retrouve, et ce n'est vraiment pas 'naturel'.

A+

[User]

Bonsoir,

Question naïve :

Pourquoi utiliser le type réel double pour stocker un montant, pourquoi ne pas utiliser le type monétaire ?

Cdlt,

[hyperion13]

C'est beau des nombres décimaux !
Si vous voulez que les décimales ne froissent pas l'esthétique du champ il vous suffirait tout simplement de le verrouiller.
D'ailleurs quelle idée d'aller cliquer sur le champ !

[marot_r]

Bonjour.

Pourquoi utiliser le type réel double pour stocker un montant, pourquoi ne pas utiliser le type monétaire ?

J'ai eu la même idée que toi et en Access 2010 je ne vois plus le type monétaire (qui de plus avait la réputation d'être bogué).
Donc je pense que M$ l'a remplacé par (silencieusement) par le type décimale ... ou alors je ne suis franchement pas réveillé.

A+

[tee_grandbois]

bonsoir Marot_r,

Bonjour.

J'ai eu la même idée que toi et en Access 2010 je ne vois plus le type monétaire (qui de plus avait la réputation d'être bogué).
Donc je pense que M$ l'a remplacé par (silencieusement) par le type décimale ... ou alors je ne suis franchement pas réveillé.

A+

réveille-toi René , le type Monétaire (Currency) n'a pas disparu, en tous cas, pas jusqu'à la version 2013 et c'est un type de données à part entière alors que Décimal est une catégorie "Taille de champ" (Size) du type de données Numérique, bien pratique, il est vrai.

Par contre, je n'ai jamais entendu parler de cette réputation que tu lui prêtes et ce, depuis 24 ans que je l'utilise ...

[Finndelle74]

Bonjour à tous, et surtout merci beaucoup pour vos réponses !

Pour le type "Décimale" c'est la propriété Échelle qui détermine le nombre de décimales.

En effet, j'étais totalement passée à côté de cette propriété "Echelle". J'ai modifié ainsi le format de mon champ, avec Echelle = 2 et cela fonctionne ! Par contre, est-ce que ce format risque de poser problème pour mes fonctions ? (ou je déclare en 'Double' en paramètre d'entée)
Et quid si le montant est issu d'une requête (montant calculé) et non d'une table ?

Pourquoi utiliser le type réel double pour stocker un montant, pourquoi ne pas utiliser le type monétaire ?

Parce que je veux reprendre ensuite mon modèle de sous-formulaire pour des données numériques autres que des montants (ex : nombre d'heures).

Si vous voulez que les décimales ne froissent pas l'esthétique du champ il vous suffirait tout simplement de le verrouiller.

J'avais essayé en effet, mais visuellement ce n'est vraiment pas beau !! (devient tout grisé)

D'ailleurs quelle idée d'aller cliquer sur le champ !

1) Parce que j'essaie de penser à toutes les bizarreries que pourrait me faire un utilisateur, et que je ne veux pas qu'on me dise que mon appli bugge parce que mes données ont plein de décimales, et que les totaux générés ensuite ne sont pas exacts ;

2) Parce qu'en fait, j'essaie de remplacer une listbox par un sous-formulaire, car j'étais très embêtée par le visuel de ma listbox avec le format numérique aligné à gauche. J'avais bien bidouillé une fonction qui me rajoutait des espaces avant, mais je devais alors prendre une police non proportionnelle, et ça restait vraiment pas très beau à voir...

La finalité, étant de reproduire le même comportement que la listbox avec mon sous-formulaire continu, et donc que l'utilisateur clique sur la ligne pour la sélectionner (et ensuite la modifier). D'ailleurs il faut encore que je trouve un moyen de m'affranchir du sélecteur qui n'est pas très beau...

Donc pour l'instant la solution de l'échelle me convient ! a suivre pour l'histoire des fonctions et champs calculés par requêtes.

[marot_r]

Ok, merci tee-Grandbois, en effet je l'avais cherché parmis les numériques (suis-je bête, la monnaies n'a rien à voir avec les nombres :-) ).

Pour le "bug".

J'ai pris l'info là :

Currency format
http://allenbrowne.com/ser-44.html

Ça touche principalement les gens qui comme moi travaillent dans un environnement bilingue qui n'utilise pas les même conventions pour la présentation des nombres.

A+

[tee_grandbois]

Bonjour,

Ça touche principalement les gens qui comme moi travaillent dans un environnement bilingue qui n'utilise pas les même conventions pour la présentation des nombres.

merci René pour l'info, mais cela concerne un environnement bien spécifique ...

[marot_r]

merci René pour l'info, mais cela concerne un environnement bien spécifique ...

En effet, désolé pour la généralisation.

A+