ORA-01843: not a valid month

Bonjour à tous,

J'ai une procédure sur deux bases différentes (TEST et PROD) qui prend une date en paramètre.

Cette procédure est identique sur les deux environnement.

Cependant lorsque je fais des tests, la procédure fonctionne sans problème sur l'environnement de TEST. Toutefois sur l'environnement de PROD, à l'exécution, j'ai l'erreur :

Citation:

---

ORA-01843: not a valid month

---

.

J'ai vérifié les paramètres des deux bases :

- Base de Test :

Code:

---

SELECT * FROM NLS_DATABASE_PARAMETERS;

---

Voici le résultat :

PARAMETER	VALUE

NLS_NCHAR_CHARACTERSET	AL16UTF16
NLS_LANGUAGE	FRENCH
NLS_TERRITORY	FRANCE
NLS_CURRENCY	?
NLS_ISO_CURRENCY	FRANCE
NLS_NUMERIC_CHARACTERS	,.
NLS_CHARACTERSET	WE8ISO8859P1
NLS_CALENDAR	GREGORIAN
NLS_DATE_FORMAT	DD/MM/RR
NLS_DATE_LANGUAGE	FRENCH
NLS_SORT	FRENCH
NLS_TIME_FORMAT	HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT	DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT	HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT	DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY	?
NLS_COMP	BINARY
NLS_LENGTH_SEMANTICS	BYTE
NLS_NCHAR_CONV_EXCP	FALSE
NLS_RDBMS_VERSION	9.2.0.8.0

- Sur la PROD :

PARAMETER	VALUE

NLS_NCHAR_CHARACTERSET	AL16UTF16
NLS_LANGUAGE	FRENCH
NLS_TERRITORY	FRANCE
NLS_CURRENCY	?
NLS_ISO_CURRENCY	FRANCE
NLS_NUMERIC_CHARACTERS	,.
NLS_CHARACTERSET	WE8ISO8859P1
NLS_CALENDAR	GREGORIAN
NLS_DATE_FORMAT	DD/MM/RR
NLS_DATE_LANGUAGE	FRENCH
NLS_SORT	FRENCH
NLS_TIME_FORMAT	HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT	DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT	HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT	DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY	?
NLS_COMP	BINARY
NLS_LENGTH_SEMANTICS	BYTE
NLS_NCHAR_CONV_EXCP	FALSE
NLS_RDBMS_VERSION	9.2.0.8.0

Le résultat est le même.

De ce fait je ne comprends pas d'où vient le problème.

Si quelqu'un a une idée je suis preneur

Il détecte un mois invalide genre 10/13/2012. Soit une erreur est présente dans tes données soit tu définis mal tes dates dans ta procédure.

Montre-nous donc ta procédure, tes tables et un extrait de données.

J'ai oublié de donner un exemple c'est vrai :

Ma procédure à un paramètre date en entrée.

J'ai constaté que si je fait appel à ma procédure sur l'environnement de PROD avec une date au format français type DD/MM/YYYY (ex: 01/01/2005), je me retrouve avec l'erreur => not a valid month.
Si j'appelle ma procédure avec le format américain (ex: 01-jan-2005) la procédure s'exécute.

Si je fais les mêmes appels sur l'environnement de TEST la procédure s'exécute et le format stocké en base correspond au format français.

Voici la déclaration de ma procédure et les exemples d'appels fait :

Code:

---

1 2 3

procedure UpdateDateNomenclature(par_dDeb In DATE) UpdateDateNomenclature('01-JAN-2005'); UpdateDateNomenclature('01/01/2005');

---

Il y a t'il un autre endroit que la table NLS_DATABASE_PARAMETERS où le format de date par défaut d'oracle peut-être paramétré?

Dans ta procédure tu peux reformater ta date avant de faire des calculs.

Quand je demandais ta procédure, c'est pas juste la déclaration ou les appels mais la procédure en elle-même.

Pour être certain de la manière dont ta chaîne de caractères est convertie en date, le plus simple est de forcer le format en utilisant TO_DATE.

Code:

---

1 2 3

procedure UpdateDateNomenclature(par_dDeb IN DATE) UpdateDateNomenclature(TO_DATE('01-JAN-2005', 'dd-mmm-yyyy')); UpdateDateNomenclature(TO_DATE('01/01/2005', 'dd/mm/yyyy'));

---

En évitant les conversions implicites, tu es sur de ne pas avoir de surprise !

Citation:

---

Envoyé par al1_24

Pour être certain de la manière dont ta chaîne de caractères est convertie en date, le plus simple est de forcer le format en utilisant TO_DATE.

Code:

---

1 2 3

procedure UpdateDateNomenclature(par_dDeb IN DATE) UpdateDateNomenclature(TO_DATE('01-JAN-2005', 'dd-mmm-yyyy')); UpdateDateNomenclature(TO_DATE('01/01/2005', 'dd/mm/yyyy'));

---

En évitant les conversions implicites, tu es sur de ne pas avoir de surprise !

---

N'est-ce pas mieux de reformater la date dans la procédure ?
Cela éviterai de reconvertir à chaque fois qu'elle est appelée.

Citation:

---

Envoyé par lola06

N'est-ce pas mieux de reformater la date dans la procédure ?
Cela éviterai de reconvertir à chaque fois qu'elle est appelée.

---

La procédure traite une date et une date n'a pas de format, il n'y a donc rien à faire dans la procédure.
Par contre '01/01/2005' n'est pas une date mais un varchar, il y aura donc conversion implicite.
TO_DATE('01/01/2005', 'dd/mm/yyyy') est une date, pas de conversion implicite dans la procédure.

La bonne méthode d'appel de la procédure est donc bien celle donnée par Al1_24.

D'ailleurs, il faut toujours préciser le format des dates qui sont saisies en varchar, pour la transportabilité du code, et surtout pour éviter ce genre d'erreurs.

Bonjour,

Merci pour vos différents retours.

Dans l'absolu, je suis tout à fait d'accord avec vous sur la précision du format de date en entrée.

Toutefois la difficulté c'est que l'appel à ma procédure est fait par un programme tiers géré par un autre éditeur. Ce programme est à la base codé en JAVA. Ils récupèrent sous forme d'une chaîne la liste des paramètres et à l'aide d'un concentrateur appel ma procédure.

Tous les appels à mes différentes procédure se font de la même façon. Et il n'y a que sur une proc que le problème se produit.

En tout cas merci de vos divers retours.

Bonjour,

Donc, personne ne saurait dire ce qui fait que le comportement diffère, entre la prod et le test, alors que la configuration NLS est conforme ?

Si du moment que le paramétrage NLS est conforme et que par rapport à Oracle il ne peut pas y avoir d'autre endroit où un paramétrage pourrait jouer, alors c'est que ça vient soit de l'OS, soit de l'environnement Java... mais où ?

Ca n'a rien à voir avec un paramétrage de la base de données, mais c'est lié à un paramétrage de la session de l'utilisateur qui se connecte.
Effectivement des paramétrages java, OS, NLS_LANG... côté client influent sur le paramétrage de la session.

Décrivez-votre problème si vous souhaitez des réponses plus adaptées.

Merci de ta réponse.

Mon problème semble parfaitement similaire à celui énoncé au départ, je ne vois pas trop quoi y ajouter.

Habituellement, l'application concernée (une webapp sous Tomcat) fonctionne bien chez les clients, en revanche, chez un nouveau client, on a une erreur ORA-01843. Ceci n'est pas étonnant car le format des dates fournies en paramètre des requêtes n'a pas été précisé (pas d'utilisation de TO_DATE()). De fait, une conversion automatique texte -> date est effectuée mais sur un format qui n'est pas le bon.

Là on cherche à identifier à quel niveau l'environnement diffère et interfère dans le format des dates transmises via JDBC, à la base Oracle (qui elle, vraisemblablement, est bien configurée)...

Dans l'absolu, je sais qu'un alter session ou l'ajout du to_date serait préférable mais en pratique on préfère éviter d'en arriver là, pour différentes raisons.

Le NLS_DATE_FORMAT est issu du NLS_TERITORY.

Une approche est de trouver les locales java qui permettent de configurer le NLS_TERITORY
Exemple :
https://stackoverflow.com/questions/...bc-thin-driver

Sinon une autre possibilité est de créer un trigger after logon afin de configurer le NLS_DATE_FORMAT avec la bonne valeur.

Donc, effectivement, il suffisait d'ajouter

Code:

---

-Duser.country=fr -Duser.language=fr

---

dans la config Tomcat (le paramétrage du service en ce qui me concerne).
Merci