Discussion :

[deaven]

Voici le problème que j'ai,

Une unité de traitement effectue une requête dans une base de donnée métric. L'unité de traitement est sur un serveur anglais. Donc mon traitement en lot prend par exemple un 7,80 dans la première base de donnée et le transfère dans une autre base de donnée qui interprète la valeur reçu comme 780 au lieu de 7,80.

C'est donc mon unité de traitement en .NET qui interprète mal la valeur après tout c'est pas sa faute il est anglais

Quelqu'un peut me donner une piste de solution à ce problème ??

Merci!

[pifor]

Pas sûr que c'est un problème de globalisation (si c'était 7.80 oui mais ce n'est pas le cas ...)

Vérifiez la valeur NLS_LANG utilisée par les 2 clients des bases de données, voir http://fadace.developpez.com/oracle/nls/

Essayez de tracer l'ordre SQL qui écrit la donnée.

[rbaraer]

deaven,

Du moment que vous manipulez les nombres en tant que tel, en mappant bien NUMBER Oracle avec un Entier ou un Réel en .NET il ne peut pas y avoir de problème de "globalisation" (c'est bien français ??? ). Les problèmes de conversion entre nombres ne pourraient apparaitre que si vous passiez par un intermédiaire en chaine de caractères avant de le reconvertir en nombre, car là vous pourriez passer de 7.8 en nombre binaire à "7,8" ou "7.8" en chaine de caractères et, si les NLS_LANG sur les 2 clients ne sont pas cohérents, avoir des conversions erronées. Gardez-vous bien les nombres en tant que tel tout le long de la chaine ?

Petite apartée : le problème est identique avec les Dates ou Timestamps mais il se pose encore plus car il est très fréquent de transporter des dates en chaines... De façon générale, toute conversion doit être EXPLICITE pour éviter les problèmes liés à des formats par défaut spécifiés par NLS. Les conversions implicites sont des nids à bugs (sans mauvais jeu de mots ). Je ne me sert de NLS_LANG que pour le jeu de caractères (et accessoirement pour les messages d'erreur).

Cordialement,

rbaraer