Migration de 8i en 10g : Format de date par défaut différent

Bonjour,

j'ai deux bases une en 8 l'autre en 10G.

Je lance un pro*cobol, qui retourne une date sous le format dd/mm/yyyy en 8 mais en 10g, le format est différent...
Pourquoi? et comment je peux résoudre cela, simplement en administrant la base, ou en changeant des paramètres d'environnement.

Merci pour votre aide.

@+

Est-ce que le paramètre NLS_DATE_FORMAT est le même pour chaque base ?
C'est le format utilisé par défaut.

je ne sais pas... en fait, j'ai pensé que mon pb venait de l'environnement UNIX... et de ce paramètre mais lorsque je lance env|grep -i nls ... il n'est pas positionné... il semblerait que ce soit la base qui gère, ou un paramètre dans une librairie cobol...

c'est un paramètre de la bd.

Citation:

---

Envoyé par Jerome_Mtl

c'est un paramètre de la bd.

---

et un paramètre de l'instance, et un paramètre de la session :
cf les vues NLS_DATABASE_PARAMETERS
NLS_INSTANCE_PARAMETERS
et NLS_SESSION_PARAMETERS

Une bonne pratique, afin de toujours avoir le même format de dates, dans une application de type PRO*XX, c'est de toujours spécifier le format de date par défaut juste après la connexion.

Par exemple, toutes mes applis PRO*C exécute l'ordre suivant juste après la connexion :

Code:

---

1 2	EXEC SQL ALTER SESSION SET NLS_DATE_FORMAT='DD-MM-YYYY HH24:MI:SS';

---

Ok merci pour ces infos... je vous tiens au courant.

Attention à l'ordre de priorité des paramètres NLS qui est le suivant dans l'ordre décroissant:

1. Défini dans l'instruction SQL
2. Défini par ALTER SESSION
3. Défini par une variable d'environnement
4. Défini par un paramètre d'initialisation
5. Défini par défaut

Si la variable d'environnement NLS_LANG est définie au niveau du client, elle va définir un format de date par défaut.

Au point de vue BDD, nous avons la même chose sauf ces deux param dans la NLS_DATABASE.

NLS_NCHAR_CHARACTERSET WE8ISO8859P1 AL16UTF16
NLS_RDBMS_VERSION 8.1.7.4.0 10.2.0.3.0

Citation:

---

Envoyé par LeoAnderson

et un paramètre de l'instance, et un paramètre de la session :
cf les vues NLS_DATABASE_PARAMETERS
NLS_INSTANCE_PARAMETERS
et NLS_SESSION_PARAMETERS

---

Excusez la simplification à outrance... :oops:

Comme je vous disais, je ne vois rien dans la base de données, qui peut engendrer ce changement dans la gestion des formats de date... Ni dans l'environnement, sauf si le NLS_LANG qui était positionné à french_america en 8i et pas positionné du tout en 10G.
J'ai alors écouté vos conseils, et donc positionné le NLS_FORMAT_DATE dans le profile de la session utilisé avec un export... pour éviter de modifier un nombre important de programmes.

Et bien, cela semble fonctionner à merveille...

Merci pour votre aide, vos conseils... qui sont très bien comme d'hab.

bye

Citation:

---

sauf si le NLS_LANG qui était positionné à french_america en 8i et pas positionné du tout en 10G.

---

rien que ça !!! :)

Du NLS_LANG, on déduit le langage et le territoire.
Le territory déterminant la façon dont les dates sont affichées par défaut....

Bon, ok, je vais en discuter avec nos DBA.

Merci pour l'info, je vais gratter de ce coté là...

J'ai deux autres questions :
Le fait de migrer d'un NLS_NCHAR_CHARACTERSET de WE8ISO8859P1 vers AL16UTF16, est-il problématique pour l'insertion de nouvelle donnée?


et pour l'exploitation, avec le nouveau paramètre, des données insérées avec l'ancien paramètre?

Merci pour vos réponses.

Ah oui, tant que nous y sommes : cela vient peut-être du même pb car dans les différentes docs que j'ai lues, j'ai vu que le NLS_LANG impacté les tris.

J'ai un problème lors de cette migration...

Je fais un select sur la base ORACLE 8i, puis sur la base ORACLE10G (Ancienne base ORACLE 8I migrée en 10G(via migrate)), l'ordre de la réponse est différente.

Merci pour vos réponses.