Discussion :

[chatroux]

Bonjour,

dans un table de ma base de données, j'ai un champ de type DATE avec des données mal formatées.

Ex :
dans mon champ j'ai 20/12/0131 (la suite de chiffres est écrite à l'envers)
au lieu de : 31/01/2012

Dans un SELECT j'ai besoin d'afficher la date avec le format 31/01/2012.

Comment faire ?
Merci d'avance

[punkoff]

Bonjour,

Pourquoi ne remettez-vous pas vos date correctement dans votre base ..?

Sinon regardez des fonctions to_char et to_date pour ce genre de problématique.

[Pomalaix]

Le cas n'est pas clair...

Si le champ est vraiment de type DATE, il ne peut pas y avoir de mauvais format.
Si c'est un VARCHAR2 par contre, c'est une autre affaire, et là effectivement il faut corriger les données (et les procédures de modification !).

Que donne tout simplement ce test basique ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT SYSDATE FROM DUAL;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT TO_CHAR(SYSDATE, 'DD/MM/YYYY') FROM DUAL;

[Rams7s]

J'ai compris que lors de l'insertion, il avaient tout melange, les annees, mois et jours. Chacun se retrouve a la place de l'autre, justement parce qu'ils oublie de mettre un masque comme dans votre exemple pomalaix.

Le mieux c'est encore de reparer les betises en faisant un update et des substr. Comme ca le probleme ne se posera plus

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
TMP@MINILHC >with tmp as (select to_date('20/12/0131','dd/mm/yyyy') as n from dual),t1 as (select n, to_char(n,'yyyy') n2,to_char(n,'ddmm') as n3 from
 tmp) select n craquage_date,substr(n2,3,2)||substr(n2,1,2)||n3 as valid_date from t1;
 
CRAQUAGE_D VALID_DA
---------- --------
20/12/0131 31012012

Et VALID_DATE se transfomr en date avec un TO_DATE(valid_date,'ddmmyyyy')

[Glutinus]

Petit conseil dans ce cas : vérifier le paramètre NLS_DATE_FORMAT avec le DBA. Il indique le format par défaut que doit prendre une date lorsqu'on l'affiche, et éventuellement lui donner un format classique DD/MM/YYYY (toujours en collaboration avec le DBA bien sûr).

Comme cela il y aura moins de confusion lors de l'insertion ou mise à jour des champs.

Personnellement, lorsque j'insère ou met à jour des dates dans Oracle je préfère toujours préciser un to_date('la_date_a_inserer','le_format'). On évite les mauvaises surprises.

[Waldar]

Petit conseil dans ce cas : vérifier le paramètre NLS_DATE_FORMAT avec le DBA. Il indique le format par défaut que doit prendre une date lorsqu'on l'affiche, et éventuellement lui donner un format classique DD/MM/YYYY (toujours en collaboration avec le DBA bien sûr).

Ce qui aura un impact limité puisque chaque session de chaque client peut changer son propre NLS_DATE_FORMAT.

Personnellement, lorsque j'insère ou met à jour des dates dans Oracle je préfère toujours préciser un to_date('la_date_a_inserer','le_format'). On évite les mauvaises surprises.

OUI ! Il faut le faire.
Notez que pour les dates sans horodatages on peut utiliser la "fonction" date avec le format ANSI :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select date '2012-02-07' as dt from dual

Qui est une écriture raccourcie de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select to_date('2012-02-07', 'yyyy-mm-dd') as dt from dual

[chatroux]

Oui Rams7s, c'est ce qu'il s'est passé. Le champ dans la BD est bien de type DATE, mais les données ont été mal formatées au moment de l'insertion.
Merci pour ton script, je vais voir comment l'utiliser