[O10R2] date étrange

Etrange comportement :

Code:

---

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

SQL> create table t (i int, d date) ; Table créée. SQL> insert into t values(1, current_date) ; 1 ligne créée. SQL> insert into t values(2, current_date) ; 1 ligne créée. SQL> insert into t values(3, to_date('21-02_2006')) ; 1 ligne créée.   SQL> select * from t ;   I D ---------- -------- 1 21/02/06 2 21/02/06 3 21/02/06     SQL> select * from t where d = current_date;   aucune ligne sélectionnée

---

je fais visiblement qqch de faux puisque j'ai ce cas bizarre aussi bien en 9.2 qu'en 10.1 ou 10.2

current_date y'a l'heure.

fait un

Code:

---

select to_char(d, 'DD.MM.YYYY HH24:MI:SS') from t

---

Citation:

---

Envoyé par McM

current_date y'a l'heure.

---

Exact ! :-)

Mais il vaut mieux ne garder que les jours par un trunc que par une conversion ! ;-)

Code:

---

1 2 3 4 5 6 7

SQL> select * from t where trunc(d) =trunc (current_date ) ;   I D ---------- ---------- 1 21/02/2006 2 21/02/2006 3 21/02/2006

---

Le problème est alors plus en avant:

J'ai une contrainte sur ma table

Code:

---

ALTER TABLE T ADD ( UNIQUE ("D") VALIDATE )

---

L'insertion de 2 dates similaires ne marche effectivement pas

Code:

---

1 2 3 4 5 6

SQL> insert into t values (10,'02-02-02') ; 1 ligne créée.   SQL> insert into t values (11,'02-02-02') ; ERREUR à la ligne 1 : ORA-00001: unique constraint (SYS.SYS_C0017641) violated

---

Par contre, l'insertion de deux dates similaires de via current_date passe. C'est comme si il checkait la current_date (heure comprise) avant l'insertion, puis qu'ayant obtenu le feu vert, il passait outre la contrainte sur le champ de type DATE... ce qui n'est pas un comportement correct !

Code:

---

1 2 3 4 5 6

SQL> insert into t values (12,current_date) ; 1 ligne créée.   SQL> insert into t values (13,current_date) ; 1 ligne créée.

---

:cry: :cry:

Il n'y a rien d'étrange : le type DATE comporte DATE + HEURE ! :-)

pourquoi alors un select to_timestamp(D) from t me retourne toutes les heures à 0 ?

Pour moi il n'y a pas de probléme

Dans ton premier ordre d'insertion étant donnée que tu ne lui donne pas l'heure il fait un trunc sur cette valeur d'ou le violated contraint :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

SQL> alter session set nls_date_format ='dd/mm/yyyy' ;   Session modifiée.   SQL> select * from t ;   I D ---------- ---------- 1 21/02/2006 2 21/02/2006 3 21/02/2006   SQL> alter session set nls_date_format ='dd/mm/yyyy hh24:mi:ss' ;   Session modifiée.   SQL> select * from t ;   I D ---------- ------------------- 1 21/02/2006 17:37:56 2 21/02/2006 17:37:56 3 21/02/2006 00:00:00   SQL>

---

dans le second ordre SQL current_date comprend d'office l'heure qui change forcément d'une seconde à une autre
donc pas de violated constraint :wink:

Ok, merci à tous... c'est juste le to_timestamp qui m'avait induit en erreur.

Comme toujours, rien ne vaut la doc ! ;-)

Representing Datetime Data: Overview

Citation:

---

Using the DATE Datatype

Use the DATE datatype to store point-in-time values (dates and times) in a table. The DATE datatype stores the century, year, month, day, hours, minutes, and seconds.
Using the TIMESTAMP Datatype

Use the TIMESTAMP datatype to store values that are precise to fractional seconds. For example, an application that must decide which of two events occurred first might use TIMESTAMP. An application that specifies the time for a job might use DATE.
Using the TIMESTAMP WITH TIME ZONE Datatype

Because TIMESTAMP WITH TIME ZONE can also store time zone information, it is particularly suited for recording date information that must be gathered or coordinated across geographic regions.
Using the TIMESTAMP WITH LOCAL TIME ZONE Datatype

Use TIMESTAMP WITH LOCAL TIME ZONE when the time zone is not significant. For example, you might use it in an application that schedules teleconferences, where participants each see the start and end times for their own time zone.

The TIMESTAMP WITH LOCAL TIME ZONE type is appropriate for two-tier applications in which you want to display dates and times that use the time zone of the client system. It is generally inappropriate in three-tier applications because data displayed in a Web browser is formatted according to the time zone of the Web server, not the time zone of the browser. The Web server is the database client, so its local time is used.

---