[9i]Conversion implicite ?

Bonsoir,

j'ai une procédure qui lit des requêtes ds une table et les exécute.

un certains type de requête me pose problème

Code:

---

1 2	update table set num = '2.2' where ident = 1

---

le champ num est un number ds la table

le fait de au moment de l'update de placer sa valeur entre ' sollicite t'il Oracle pour une conversion implicite de Varchar vers Number ?

Le serveur est en AMERICAN.AMERICA

ma procédure me renvoit l'erreur suivante :

Code:

---

Code erreur : -1722 - Libellé erreur : ORA-01722: invalid number

---

bizarrement si je mets une "," à la place du "." ca semble passer mieux

en placant un alter session pour forcer NLS_language et NLS_TERRITORY en AMERICA et AMERICAN en début de procédure j'obtiens qq chose de bien à la première exécution de la procédure qui est commandée par un job, mais dans les éxecutions suivantes survient à nouveau le problème...

quelqu'un a t'il déjà rencontré ce type de problème ? instabilité due à une conversion implicite ?

Merci d'avance

Luna

Bonjour,

Tu es confronté à un problème de NLS.

1) oui, le fait de mettre '2.2' implique une conversion implicite d'une chaîne de caractères vers un nombre

2) la conversion se fait dans ton cas via les paramètres NLS. Tu peux consulter les paramètres de ta session via la vue :

Code:

---

select * from nls_session_parameters ;

---

Regarde en particulier ce que vaut le paramètre NLS_NUMERIC_CHARACTERS. Il donne 2 caractères que l'on appelle dg. Peut-être as-tu ,. comme valeur, ce qui signifie d=, et g=.

d est le séparateur numérique
g est le séparateur des milliers

Rien n'empêche de les modifier via un :

Code:

---

alter session set NLS_NUMERIC_CHARACTERS='.,' ;

---

car fixer les paramètres NLS_LANGUAGE et NLS_TERRITORY ne suffit pas toujours.

3) un moyen de s'affranchir des paramètres NLS est de spécifier le format en utilisant la fonction TO_NUMBER. Par exemple, si je veux mettre 2500,5 :

Code:

---

update test set num = to_number ('2.500,5', '9G999D9', 'NLS_NUMERIC_CHARACTERS='',.''') ;

---

4) au niveau de la planification de ton job : je pense que ton pb provient de ce que je te disais au point 2). Essaye de jouer sur le NLS_NUMERIC_CHARACTERS

5) lorsque tu planifies un job via la procédure DBMS_JOB.SUBMIT, il faut savoir qu'Oracle récupère tes paramètres NLS de session, et les stocke. Tu peux voir ces paramètres en regardant la colonne NLS_ENV de la vue USER_JOBS.

Au final, tu peux donc gérer les paramètres NLS via un ALTER SESSION dans ta procédure stockée, ou bien les positionner correctement avant le SUBMIT de ton job.

Ca doit cool d'être bon !!

j'ai fait un

Code:

---

1 2	select * from user_jobs where job = 9;

---

et tiens tiens ca renvoit ça...

Code:

---

1 2 3 4

9 GEOPC_SL GEOPC_SL GEOPC_SL 13-APR-07 10:02:17 13-APR-07 10:03:17 2459 N sysdate + 1/(60*24) 0 GEOPC_SL.MAJ_DATA_GEOPC; NLS_LANGUAGE='FRENCH' NLS_TERRITORY='FRANCE' NLS_CURRENCY='€' NLS_ISO_CURRENCY='FRANCE' NLS_NUMERIC_CHARACTERS=', ' NLS_DATE_FORMAT='DD/MM/RR' NLS_DATE_LANGUAGE='FRENCH' NLS_SORT='FRENCH' 0102000200000000

---

je ne comprends rien car le système ds le SPFILE est bien en AMERICA
AMERICAN avec Numeric Character '.,'

ou va t'il me chercher ce french france à la création du Job ?

merci de tes indications

je crois que j'ai bien compris le problème et donc compris la solution....

Luna

En général les valeurs des paramètres NLS du fichier d'initialisation sont des valeurs par défaut uniquement prises en compte si NLS_LANG (variable d'environnement Unix ou clé de registre Windows) n'est pas définie par le client qui se connecte à la base.

Quelle est la valeur de NLS_LANG côté client ?
Que retourne:

Code:

---

SELECT * FROM nls_session_parameters ;

---

Bonjour Pifor

ci dessous ta requête executer sur un poste client correctement paramétré, à mon avis il faudrait executer ca sur le serveur pour que cela ait une réelle signifcation

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

PARAMETER VALUE ------------------------------ ---------------------------------------- NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY $ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS ., NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD-MON-RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH.MI.SSXFF AM NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY $ NLS_COMP BINARY NLS_LENGTH_SEMANTICS BYTE NLS_NCHAR_CONV_EXCP FALSE

---

Ceci dit en plaçant des

Code:

---

1 2 3 4

ALTER SESSION set NLS_LANGUAGE = 'AMERICAN' ALTER SESSION set NLS_TERRITORY = 'AMERICA' ALTER SESSION set NLS_NUMERIC_CHARACTERS = '.,'

---

Tout va beaucoup mieux !!!

Néanmoins je suis trés interrésé par ce que tu me dis rouardg :

Citation:

---

Au final, tu peux donc gérer les paramètres NLS via un ALTER SESSION dans ta procédure stockée, ou bien les positionner correctement avant le SUBMIT de ton job.

---

je n'ai pas trouvé la syntaxe pour spécifier les paramètres NLS ds le SUBMIT de mon Job

Merci d'avance

Luna

Citation:

---

je n'ai pas trouvé la syntaxe pour spécifier les paramètres NLS ds le SUBMIT de mon Job

---

Normal, car la manipulation consiste d'abord à faire des ALTER SESSION... au sein de ta session, pour avoir les bons paramètres NLS, puis à faire un SUBMIT de ton job.

A ce moment-là (au SUBMIT), Oracle récupère les paramètres NLS, puis les stocke dans la table DBA_JOBS.

Du coup, lorsque ton job va se déclencher, il devrait se déclencher avec les paramètres stockés dans DBA_JOBS.

Ben voilà... on a fait le tour de ce sujet trés intérressant

Merci à vous 2 pour toutes ces infos super !

et bon weekend

a+

Luna

Bonjour à tous,

Bien que ce sujet est résolu j'ai encore quelques questions au niveau des conversions
- au niveau de sql*loader, qu'est-il possible de faire ? (bd en language american, et on veut charger du french, peut-on temporairement durant le chargement forcer language à french ?)
- peut on définitivement changer les nls information ? comment ? dans ora.init ?

Merci d'avance.

Cordialement.