Heure incohérente pour Oracle 8i, il est 16 H 60 !

[zorino]

Bonjour,

Comme indiqué Par SQL+ (voir pièce jointe), une valeur de champ DATE dans une table fait délirer Oracle 8i, planter TOAD et mon programme (Delphi).

Cette valeur est insérée dans la table par du code Delphi qui fait, en gros :
Table.Insert;
Champ.AsString := AutreChamp.AsString (valeur 08/09/2007 15:59:00)
Table.Post;

Outre la méthode, discutable (mais ce n'est pas le sujet), je voudrais savoir ce qui pose pb à Oracle et comment y remédier à l'avenir.

Merci à ceux qui ont déjà rencontré le pb de m'aider, je ne m'en sors pas !

[LeoAnderson]

Manifestement, la méthode discutable est en cause !

la colonne est une date ?

Code :

DESC zcc

Dans ce cas, pourquoi convertir en chaine, sans préciser de format ?

[orafrance]

Merci de changer le titre pour rendre la discussion plus claire

[zorino]

Par défaut, Delphi utilise le format de date courte de Windows (et ça fonctionne très bien, toute l'application fait ça, ça représente des millions de lignes sans pb...).
Ce que je voudrais savoir, c'est ce qui gêne Oracle ?
Après tout, une date est un flottant... Cela voudrait-il dire qu'il y a des valeurs de flottants qui font qu'Oracle se vautre ? Est-ce un pb connu ?
Faut-il faire un arrondi de sioux ?

Merci pour ton aide.

[orafrance]

ce qui géne c'est que tu stockes une donnée qui est une chaine de caractère et pas une date... donc tu peux même mettre 32/13/1950 25:60:97 si ça te change

une date c'est pas un flottant, c'est une date donc un type qui a des propriétés particulières

Edit : après avoir revu l'erreur... ça ressemble furieusement à un bug de TO_CHAR quand même

[zorino]

Envoyé par orafrance

une date c'est pas un flottant, c'est une date donc un type qui a des propriétés particulières

Quelles propriétés ?
C'est peut-être là que je dois creuser ?
Parce que le champ d'origine, comme indiqué dans le 1er post, est une date valide qui ne fait pas couiner Oracle : 08/09/2007 17:59:00

[orafrance]

propriété de date classique : pas plus de 24h/j, 60 min/h, 60s/min, etc...

tu veux pas faire un desc de ta table comme le suggére leo ?

et que donne :

Code :

SELECT TO_DATE('08/09/2007 16:60:01', 'DD/MM/YYYY HH24:MI:SS) FROM dual

ça plante en principe non ?

et la version compléte de la base ?

[orafrance]

essaye :

Code :

1
2
ALTER session SET nls_date_format='DD/MM/YYYY HH24:MI:SS';
SELECT date1 FROM zcc

[LeoAnderson]

A mon avis, des conversion sous delphi sans préciser de formats ont dû "corrompre" la colonne (rien ne dit que delphi appelle to_date... il convertit peut-être lui même en float à sa sauce et passe le float à Oracle qui le convertit en date).

D'où l'importance du desc !

[zorino]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SQL> ALTER session SET nls_date_format='DD/MM/YYYY HH24:MI:SS';
 
Session modifiée.
 
SQL> SELECT * FROM zcc;
 
       IDF DATE1                DATEFLOAT
---------- ------------------- ----------
      1000 18/09/2007 16:60:01          0
 
SQL> DESC zcc
 Nom                                       NULL ?   Type
 ----------------------------------------- -------- ----------------------------
 IDF                                       NOT NULL NUMBER(9)
 DATE1                                              DATE
 DATEFLOAT                                          NUMBER(6,10)

Le champ DATEFLOAT ne sert à rien, oubliez-le.

Je suis d'accord avec toi, Leo, la conversion doit être à l'origine du pb. Mais pourquoi ?
Les décimales correspondent à des fractions de temps : 1 seconde = 1/86400 = 0,0000115741 qui est un arrondi à la 10ème décimale car l'opération ne se termine jamais, il y a une suite de 740740 etc...
Donc, en principe, si la plus petite unité gérée par Oracle est la seconde, les champs devraient contenir des multiples de 0,0000115740. Mais Oracle ne couine pas s'ils contiennent autre chose, il arrondit à la seconde et c'est tout (du moins j'en ai l'impression). Donc je ne vois pas ce qui peut poser pb... or il y en a bien un, et un gros !
De plus, je le répète, ce sont chaque mois des centaines de millions de lignes qui sont ainsi insérées sans pb et, à ma connaissance, ce bug de date ne s'est produit que 3 ou 4 fois...

[zorino]

Code :

1
2
3
4
5
6
7
8
9
SQL> SELECT * FROM v$version;
 
BANNER
----------------------------------------------------------------
Oracle8i Release 8.1.7.4.1 - Production
PL/SQL Release 8.1.7.4.0 - Production
CORE    8.1.7.2.1       Production
TNS FOR 32-bit Windows: Version 8.1.7.4.0 - Production
NLSRTL Version 3.4.1.0.0 - Production

[orafrance]

si tu envoies des 0,0000115741 dans des colonnes DATE j'veux bien croire qu'Oracle bug... il n'est pas aussi précis

Ca doit être un bug référencer chez Delphi c'est pas possible autrement

[zorino]

Envoyé par orafrance

si tu envoies des 0,0000115741 dans des colonnes DATE j'veux bien croire qu'Oracle bug... il n'est pas aussi précis

je n'envoie rien, je cherche juste à comprendre...
Oracle stocke une date avec l'heure 15:59:00 sous cette forme ; ,665972
Or, c'est bien le résultat de l'opération ((15 x 3600) + (59 x 60) ) / 86400.
Donc j'en conclus qu'une seconde vaut 0,0000115741, c'est tout...
Mais si, au lieu d'ajouter 0,0000115741 j'ajoute juste 0,0000115000, par exemple, Oracle ne couine pas, il arrondit. Donc je me demande ce qui le fait couiner dans mon cas

Et je vais maintenant espérer que ce cas s'est déjà produit pour un autre visiteur de ce forum...

[orafrance]

Envoyé par zorino

Oracle stocke une date avec l'heure 15:59:00 sous cette forme ; ,665972

ha bon ? Comment t'as vu qu'il stocke ça comme ça ?

[DAB.cz]

Stockage de date (j'ai lu dans cet forum?):

Code :

1
2
3
4
5
SQL> SELECT dump (sysdate) FROM dual;
 
DUMP(SYSDATE)
-------------------------------------
Typ=13 Len=8: 215,7,11,27,20,2,12,0

siècle, année, mois, jour, heure....

10g - même à 8i?

DAB

[LeoAnderson]

Sur une 8i :

Code :

1
2
3
4
5
6
7
8
9
10
11
SQL> SELECT dump(sysdate) FROM dual;
 
DUMP(SYSDATE)
--------------------------------------------------------------------------------
Typ=13 Len=8: 7,215,11,28,6,53,38,0
 
SQL> SELECT dump( 145234 / 932148621) FROM dual;
 
DUMP(145234/932148621)
--------------------------------------------------------------------------
Typ=2 Len=21: 191,2,56,81,57,27,63,23,81,87,91,94,30,89,4,48,49,17,28,62,6

C'est pas le même type.

Note metalink 69028.1

Since Oracle 7 the DATE datatype is stored in a proprietary format. DATE values
are always stored in 7 bytes, excluding the length byte, within a datafile.
These bytes store the century, year, month, day, hour, minute, and second
details respectively. The following is the definition of Oracle's internal DATE
storage structure :
BYTE Meaning
---- -------
1 Century -- stored in excess-100 notation
2 Year -- " "
3 Month -- stored in 0 base notation
4 Day -- " "
5 Hour -- stored in excess-1 notation
6 Minute -- " "
7 Second -- " "

Avant de raconter quelque chose, prenez la peine de vérifier !

Faites un dump de votre colonne corrompue et vous verrez d'où vient l'erreur... je suis prêt à parier que 6 vaut 60 au lieu de valoir 0.

[zorino]

Envoyé par LeoAnderson

Faites un dump de votre colonne corrompue et vous verrez d'où vient l'erreur... je suis prêt à parier que 6 vaut 60 au lieu de valoir 0.

euh... comment on fait ça ?
J'ai oublié de préciser, mais ça doit sauter aux yeux , que je ne connais pas grand chose à Oracle...

[orafrance]

la syntaxe a déjà été donné maintes fois :

Code :

SELECT dump(date1) FROM zcc;

[LeoAnderson]

Y'a pile-poil deux exemples dans ma précédente réponse....

[zorino]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SQL> ALTER session SET nls_date_format='DD/MM/YYYY HH24:MI:SS';
 
Session modifiée.
 
SQL> SELECT * FROM zcc;
 
       IDF DATE1                DATEFLOAT
---------- ------------------- ----------
      1000 18/09/2007 16:60:01          0
 
SQL> SELECT dump(date1) FROM zcc;
 
DUMP(DATE1)
---------------------------------------------------------------
Typ=12 Len=7: 120,107,9,18,17,61,2

Si j'ai bien tout compris, c'est le 61 qui pose pb ?
Donc, admettons que ce soit l'instruction Delphi qui soit foireuse (une fois sur des millions) : comment elle fait ?
Expliquez-moi svp comment je peux provoquer ça, ça m'aidera peut-être à trouver dans le code l'origine du pb...
Ensuite, comme je ne ppeux pas corriger tout le code, la solution la plus simple pour garantir que tout est ok me paraît un trigger after insert et after update pour faire ce DATE+0.5 -0.5 qui semble tout remettre d'aplomb. Mais je trouve ça coûteux, voyez-vous une autre solution ?
Merci pour votre aide.