Discussion :

[NGasparotto]

Bien sûr la valeur par défaut ne marche que lors de la création (INSERT), pas lors de la mise-à-jour (UPDATE)

Et en plus il ne faut pas mentionner cette colonne lors de l'INSERT... si un developeur y met null, alors on est chocolat.
Perso, pour les colonnes d'audit, un trigger est bien mieux.
Ou alors je dois aussi etre farigue :-)

Nicolas.

[NGasparotto]

J'ai l'impression que les choses sont un peu plus compliqués parce que, sauf erreur de ma part, cette fonction n'existe pas dans la doc Oracle.
J'ai trouve seulement un wm_overlap qui n'est pas loin mais...

Ce n'est pas documente.
Tu peux lire un bon article la dessus :
http://oraclesponge.wordpress.com/20...aps-predicate/

Nicolas.

[pifor]

Les dates n'ont pas de format, on ne le répétera jamais assez.
Le format, c'est juste pour l'affichage.

Il y a un format interne de stockage et un format de manipulation qui sont différents. Mais le format de manipulation sert aussi à modifier la date car il faut bien écrire le littéral dans le format de manipulation pour pouvoir écrire une valeur dans une colonne de type DATE si l'application doit passer un littéral (une valeur en dur).

[mnitu]

...
Tu peux lire un bon article la dessus :
http://oraclesponge.wordpress.com/20...aps-predicate/

Nicolas.

Regarde l'exemple que j'ai posté

[mnitu]

...
Perso, pour les colonnes d'audit, un trigger est bien mieux.
Ou alors je dois aussi etre farigue :-)

Nicolas.

Un trigger ajoute un surcharge. Parfois ça compte. Mais cella ne veut pas dire que ce n'est pas une solution. Toute simplement une application peut fournir les valeurs et souvent c'est assez.

[NGasparotto]

Un trigger ajoute un surcharge. Parfois ça compte. Mais cella ne veut pas dire que ce n'est pas une solution. Toute simplement une application peut fournir les valeurs et souvent c'est assez.

Certes, il y a un impact sur les perf. Solution a voir avec chaque cas, tu as raison.

Nicolas.

[Invité]

Il y a un format interne de stockage et un format de manipulation qui sont différents. Mais le format de manipulation sert aussi à modifier la date car il faut bien écrire le littéral dans le format de manipulation pour pouvoir écrire une valeur dans une colonne de type DATE si l'application doit passer un littéral (une valeur en dur).

Oui, je suis d'accord, mais dans la pratique, il est fort sage de TOUJOURS préciser explicitement le format avec un to_date('08/07/2009','DD/MM/YYYY')...
Entre les applications qui changent implicitement de format, les triggers qui modifient le nls_date pour certaines sessions, les fichiers login.sql pour sqlplus, les options de oracle sql developer...
Sans parler du code qui voyage entre bd et qui ne sont pas paramétrer avec le même NLS_DATE.
Ne pas trop compter sur ce NLS_DATE : un mot d'ordre : méfiance !!!

[Hamdi Hedhili]

Merci de votre aide.

Ce sujet est clos

[laurentschneider]

Et en plus il ne faut pas mentionner cette colonne lors de l'INSERT

Bon, à partir d'Oracle 9 on peut faire

Code :

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

insert into t values (default,default,default);

Quand au valeurs dates par défaut, il y a un chouette bug dans Oracle 11.1.0.6

Code :

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

1
2
3
4
5
6
create table t as select * from dual;
alter table t add (d date default sysdate not null);
select * from t;
D D        
- ---------
X 00-000-00

[orafrance]

il est pas mal celui-là

[NGasparotto]

Quand au valeurs dates par défaut, il y a un chouette bug dans Oracle 11.1.0.6

Code :

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

1
2
3
4
5
6
create table t as select * from dual;
alter table t add (d date default sysdate not null);
select * from t;
D D        
- ---------
X 00-000-00

Laurent,
Je me souviens effectivement de ce bug :
http://forums.oracle.com/forums/thre...sageID=2475835

Nicolas.