Discussion :

[jeanphy]

Re-bjr,

l'attribution d'un valeur numérique décimale dans un champ SQL numarique est IMPOSSIBLE, si LANG=fr_FR !!

Exemple,

DataModule1.CDS_patients.FieldValues(['total']):=12.56;
Post;
ApplyUpdates('1);
Refresh;

La valeur inscrite est non pas 12.56 MAIS 12!
Quand ce n'est pas zero.

Si vous remplacez 12.56 par un variant '12,56' ou un Double=12.56 ou autre, c'est pareil.

IBConsole, IBAccess, DBExplorer se comportent de la meme façon, sauf si LANG n'est pas précisé ou est à us_US

Interbase, RH7.3, Suse8.1, Kylix3, Kylix2.

haha, comment faire ????? passer sous LANG=us_US et se passer des accents ??

Quelqu'un peut il répondre ????

Delphi se comporte il de la meme façon ?

Mettre DEcimalSeparator à * '.' ??

[RDM]

ca donne quoi ca ?

DataModule1.CDS_patients.FieldByName('total').AsFloat := 12.56

[jeanphy]

Kylix 2

ben ... ça donne zero

Si je remplace 12.56 par un variant, ça veut bien me donner la partie entière (12)..

dans les 2 cas, c'est fô de chez fÔ

Chez toi, ça donne quoi ?
Avec LANG=fr_FR ?

C'est la glib qui merde ?

[jeanphy]

J'ai trouvé un bricolage:

faut passer les ordres SQL en direct avec
SQLCOnnection.Execute('ordes SQL')

C'est pas très élégant, mais bon, je ne vois pas d'autres solutions...

[RDM]

encore une fois c'est la variable LC_ALL qui va déterminer ta localisation

essaye de la passer en string sinon
ou essaye de voir ceque fait une conversion d'un float en string

Edit1.Text := FLoatToStr(12.56);

[jeanphy]

avec Redhat7.3, ça donne 0,000012
avec Suse8.1 ça donne 12,56

parcontre DbExpress donne des valeurs fausses...

LC_ALL et LANG à fr_FR

expérons que United Linux ou autre harmonise tout ça ...


merci pour tout.

a+