Discussion :

[Patrick25300]

Bonjour à tous

Le type float n’ayant pas d’échelle, l’affichage des données de l’application et suivant le réglage des options régionales, les champs m’affichent de fausse valeur dans la partie décimale de mon application et certains champs en ayant les mêmes propriétés affichent en notation scientifique.

D’où mes questions ?
Pour les devises monétaires, quelles sont les valeurs que vous mettez pour le type décimal pour la précision et l’échelle, faut-il mettre un maximum pour être tranquille ? Par exemple DECIMAL(15,15).

Pour la gestion d’une quantité d’une gestion de stock que mettez vous ?

Merci de vos réponses

[TryExceptEnd]

Pour les valeurs monétaires j'utilise le type NUMERIC(18,2) et pour les quantités le NUMERIC(18,4), qui sont enregistré en BIGINT en interne qui permet une grande précision mais attention aux débordements lors des multiplications et divisions, il faut toujours caster (CAST) les résultats.

[Patrick25300]

Merci TryExceptEnd
Je prends note de tes conseils, je vais voir si d'autres idées me sont proposées pour mettre ce post comme résolu.

[dehorter olivier]

Juste des réflexions

Pour les valeurs monétaires, j'ai pu voir que les valeurs des taux de change sont à 5-6 chiffres après la virgules

Pour les quantités, j'utiliserais 2 domaines. Un pour les valeurs finies, et une pour les valeurs infinies.
exemple :
Integer : pour les bouteilles de bière
NUMERIC(18,2) : pour les litres de bière

[SergioMaster]

idem que TryExceptEnd sauf que mes quantités sont en NUMERIC(18,5) en fait cela va dépendre des unités gérées

[Patrick25300]

Je vous remercie tous de vos réponses.
Je vois aussi que vous utilisez NUMERIC plutôt que DECIMAL, il est clair que pour des valeurs de quantité ou monétaire, suivant la précision de ce qu'il y a à gérer la partie décimale a son importance, pour mon cas, je pense mettre NUMERIC(18,3) trois chiffres après la virgule ça m'est suffisant.
Salutation