PB d'insertion de date

**dalton5** · 17/02/2007, 05h09

Bonjour,

Je vous écris car j'ai un problème dans l'insertion d'une date.

Voici mon script de création de ma table

/*==============================================================*/
/* Table : PASSENGER */
/*==============================================================*/
create table PASSENGER (
ID_PASSENGER INTEGER not null,
ID_FLIGHT VARCHAR2(20) not null,
ID_SEAT INTEGER not null,
ID_GROUP INTEGER not null,
CLASS VARCHAR2(1024) not null,
CATEGORY VARCHAR2(30),
VALIDITY SMALLINT not null,
STATUS VARCHAR2(12) not null,
FIRST_NAME_PASSENGER VARCHAR2(30) not null,
LAST_NAME_PASSENGER VARCHAR2(30) not null,
TEL VARCHAR2(30),
ADDRESS VARCHAR2(30),
ZIPCODE VARCHAR2(30),
CITY VARCHAR2(30),
PHOTOS VARCHAR2(30),
BIRTH_DATE DATE,
SEX VARCHAR2(30),
EXPIRATION_DATE DATE,
NATIONNALITY VARCHAR2(30),
WITHDRAWAL SMALLINT,
WITHDRAWAL_REASON VARCHAR2(30),
constraint PK_PASSENGER primary key (ID_PASSENGER)
);

Bon jusq'ici tout va bien.

Au début du script d'insertion, j'ai:

ALTER SESSION SET NLS_DATE_FORMAT = 'dd.mm.yyyy hh24:mi:ss';

Puis ^pour insérer mes données j'ai cette ligne:

insert into PASSENGER (ID_PASSENGER, ID_FLIGHT, ID_SEAT, ID_GROUP, CLASS, CATEGORY, VALIDITY, STATUS, FIRST_NAME_PASSENGER, LAST_NAME_PASSENGER, TEL, ADDRESS, ZIPCODE, CITY, PHOTOS, BIRTH_DATE, SEX, EXPIRATION_DATE, NATIONNALITY, WITHDRAWAL, WITHDRAWAL_REASON)
values (4, '883Z', 4, 4, '1', 'VIP', 1, '1', 'Michel ', 'Drucker', '0687689045', '223 RUE DE LA SAUTERIE',
'75016', 'Paris', 'Chemin','17.02.2007 09:29:17','M', '03.10.2009 04:40:16','French',1,'Perte du passeport');

Et là oracle me dit:

Le modèle du format de date se termine avant la conversion de la chaîne d'entrée entière

Est ce que vous auriez une idée d'où peut provenir l'erreur?

**NGasparotto** · 17/02/2007, 09h18

Le code mentionné fonctionne très bien sur ma 10.2 :

Code :

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

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
SQL> create table PASSENGER (
  2  ID_PASSENGER INTEGER not null,
  3  ID_FLIGHT VARCHAR2(20) not null,
  4  ID_SEAT INTEGER not null,
  5  ID_GROUP INTEGER not null,
  6  CLASS VARCHAR2(1024) not null,
  7  CATEGORY VARCHAR2(30),
  8  VALIDITY SMALLINT not null,
  9  STATUS VARCHAR2(12) not null,
 10  FIRST_NAME_PASSENGER VARCHAR2(30) not null,
 11  LAST_NAME_PASSENGER VARCHAR2(30) not null,
 12  TEL VARCHAR2(30),
 13  ADDRESS VARCHAR2(30),
 14  ZIPCODE VARCHAR2(30),
 15  CITY VARCHAR2(30),
 16  PHOTOS VARCHAR2(30),
 17  BIRTH_DATE DATE,
 18  SEX VARCHAR2(30),
 19  EXPIRATION_DATE DATE,
 20  NATIONNALITY VARCHAR2(30),
 21  WITHDRAWAL SMALLINT,
 22  WITHDRAWAL_REASON VARCHAR2(30),
 23  constraint PK_PASSENGER primary key (ID_PASSENGER)
 24  );
 
Table created.
 
SQL> 
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'dd.mm.yyyy hh24:mi:ss';
 
Session altered.
 
SQL> 
SQL> 
SQL> insert into PASSENGER (ID_PASSENGER, ID_FLIGHT, ID_SEAT, ID_GROUP, CLASS, CATEGORY, VALIDITY, S
TATUS, FIRST_NAME_PASSENGER, LAST_NAME_PASSENGER, TEL, ADDRESS, ZIPCODE, CITY, PHOTOS, BIRTH_DATE, S
EX, EXPIRATION_DATE, NATIONNALITY, WITHDRAWAL, WITHDRAWAL_REASON)
  2  values (4, '883Z', 4, 4, '1', 'VIP', 1, '1', 'Michel ', 'Drucker', '0687689045', '223 RUE DE LA
 SAUTERIE',
  3  '75016', 'Paris', 'Chemin','17.02.2007 09:29:17','M', '03.10.2009 04:40:16','French',1,'Perte d
u passeport');
 
1 row created.
 
SQL>

Une remarque cependant, il est fortement recommandé d'utiliser le masque de date directement sur le champ date, et non à travers un alter session.

Nicolas.

**Pomalaix** · 17/02/2007, 13h35

Envoyé par NGasparotto

Une remarque cependant, il est fortement recommandé d'utiliser le masque de date directement sur le champ date, et non à travers un alter session.

Ah ?? Recommandé par qui et pourquoi ?

**NGasparotto** · 17/02/2007, 14h05

Envoyé par Pomalaix

Ah ?? Recommandé par qui et pourquoi ?

Recommandé par le bon sens des règles de développement, et parce que si l'insert est fait sans qu'il y ait eu l'alter session (et donc que le format de date de la session ne correspond pas forcément à celui utilisé dans la requête), il y a le message d'erreur qu'a eu initialement dalton5 dans son post, à savoir :

Code :

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

1
2
3
4
5
6
7
8
9
SQL> insert into PASSENGER (ID_PASSENGER, ID_FLIGHT, ID_SEAT, ID_GROUP, CLASS, CATEGORY, VALIDITY, STATUS, FIRST_NAME_PASSENGER, LAST_NAME_PASSENGER, TEL, ADDRESS, ZIPCODE, CITY, PHOTOS, BIRTH_DATE, SEX, EXPIRATION_DATE, NATIONNALITY, WITHDRAWAL, WITHDRAWAL_REASON)
  2  values (4, '883Z', 4, 4, '1', 'VIP', 1, '1', 'Michel ', 'Drucker', '0687689045', '223 RUE DE LA SAUTERIE',
  3  '75016', 'Paris', 'Chemin','17.02.2007 09:29:17','M', '03.10.2009 04:40:16','French',1,'Perte du passeport');
'75016', 'Paris', 'Chemin','17.02.2007 09:29:17','M', '03.10.2009 04:40:16','French',1,'Perte du pas
                           *
ERREUR à la ligne 3 :
ORA-01830: Le modèle  du format de date se termine avant la conversion de la chaîne d'entrée entière

SQL>

Ce genre d'erreur est facilement évitable si le code contient le masque du format de date :

Code :

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

1
2
3
4
5
6
7
SQL> insert into PASSENGER (ID_PASSENGER, ID_FLIGHT, ID_SEAT, ID_GROUP, CLASS, CATEGORY, VALIDITY, STATUS, FIRST_NAME_PASSENGER, LAST_NAME_PASSENGER, TEL, ADDRESS, ZIPCODE, CITY, PHOTOS, BIRTH_DATE, SEX, EXPIRATION_DATE, NATIONNALITY, WITHDRAWAL, WITHDRAWAL_REASON)
  2  values (4, '883Z', 4, 4, '1', 'VIP', 1, '1', 'Michel ', 'Drucker', '0687689045', '223 RUE DE LA SAUTERIE',
  3  '75016', 'Paris', 'Chemin',to_date('17.02.2007 09:29:17','dd.mm.yyyy hh24:mi:ss'),'M', to_date('03.10.2009 04:40:16','dd.mm.yyyy hh24:mi:ss'),'French',1,'Perte du passeport');

1 ligne créée.

SQL>

Nicolas.

**dalton5** · 17/02/2007, 14h35

Merci à tous pour votre aide.

Super cool se forum!!

Bonne journée...

Alex

**Pomalaix** · 17/02/2007, 15h17

Envoyé par NGasparotto

Recommandé par le bon sens des règles de développement

Répéter le même format en dur à chaque manipulation de date, c'est le contraire du bon sens !!!

Après tout est une question de contexte :
si on est certain que l'utilisateur n'a pas la main sur la variable NLS_DATE_FORMAT, on peut la définir en début de session via l'application, ou par un déclencheur ON LOGON.
Si cette condition n'est pas certaine, utiliser une variable de format de date dédiée au sein de l'application me paraît être le minimum syndical.

**NGasparotto** · 17/02/2007, 17h21

Envoyé par Pomalaix

Répéter le même format en dur à chaque manipulation de date, c'est le contraire du bon sens !!!

Après tout est une question de contexte :
si on est certain que l'utilisateur n'a pas la main sur la variable NLS_DATE_FORMAT, on peut la définir en début de session via l'application, ou par un déclencheur ON LOGON.
Si cette condition n'est pas certaine, utiliser une variable de format de date dédiée au sein de l'application me paraît être le minimum syndical.

Je ne vois pas ce qu'il y a de choquant, et de contraire au bon sens, de mettre le format de date embarquée dans la requête. Tu parles de mettre "en dur" le format de la date, mais il s'agit de la requête elle-même qu'il faut bien écrire à un moment donné en toute lettre. Ce n'est pas comme une valeur "en dur".
Après tout, il faut bien s'assurer à un moment ou un autre de ce que l'on saisi. Et c'est le seul moyen d'être sur et de ne pas se poser de question.

Nicolas.

**remi4444** · 17/02/2007, 21h26

je suis entierrement d'accord avec Nicolas, c'est une histoire de consistence de données. C'est quand meme plus sain quand la requête se suffit à elle même, plutot que ses valeurs dépendent de l'environnement. De toutes façons, le to_date est fait de manière implicite par oracle si on ne le met pas en dur... et la conversion implicite est une véritable calamité pour la stabilité d'un code

**pifor** · 19/02/2007, 08h45

Je pense que tout cela dépend de la façon dont le système supporte ou non les environnements nationaux (langue, format de date, de nombre, etc). Soit le système impose un fonctionnement statique qu'on ne peut pas modifier: dans ce cas, ALTER SESSION doit règler le problème et il est inutile de convertir explicitement les dates dans chaque requête. Soit le système est dynamique, les règles peuvent être changées au démarrage de la session, pour chaque client, voire en cours de session: dans ce cas, on ne peut pas prévoir quel sera le choix de la session et alors il faut convertir explicitement les dates dans chaque requête.

Envoyé par remi4444

C'est quand meme plus sain quand la requête se suffit à elle même, plutot que ses valeurs dépendent de l'environnement

En théorie oui mais en pratique avec Oracle on ne peut pas être complètement indépendant du jeu de caractères du client qui lui ne peut être configuré que par NLS_LANG, forcément défini au niveau du système en dehors de la base de données ...

Envoyé par remi4444

et la conversion implicite est une véritable calamité pour la stabilité d'un code

Beaucoup de langages font des conversions implicites: je dirais que le problème est plus dans la méconnaissance du langage en question que dans le mécanisme en lui-même.

**plaineR** · 19/02/2007, 09h58

Je rejoins Nicolas et Rémi, il me semble plus propre de spécifier le to_date dans la requête d'insertion. De plus prendre cette habitude évite de faire des erreurs plus grosses comme des calculs sur des chaînes de caractères.

Pour ce qui est du besoin ou non de spécifier le format dans le to_date, je suis entièrement d'accord avec Pierre : tout dépend de l'environnement. Mais comme de nombreux développeurs ignorent souvent l'environnement dans lequel va être déployée leur appli, je suis néanmoins favorable de mettre le format dans le to_date.

PB d'insertion de date

Oracle

Discussions similaires

Partager

Partager