Locale utilisée lors d'un import de données avec dbimport [Résolu]

[geekomono]

Bonjour,

Je cherche à importer un dump avec la commande dbimport sur un IDS 7.31 UD6 (toujours le même pour le fan club de mes soucies avec IDS ). Au moment d'insérer certains tuples j'ai cette erreur :

Code :

1205 - Invalid month IN date

Erreur classique car j'en ai trouvé beaucoup de similaires sur le net. Le problème vient du fait que j'essaye d'insérer une date au format MMDDYYYY dans une base dont les champs DATE suivent apperement le format DDMMYYYY. J'ai donc précisé la variable d'environnement DBDATE=MDY4/ et relancer le serveur mais celà ne règle en rien le problème. A noter qu'à ce stade un INSERT en ligne de commande fonctionne correctement et avec le format MDY4/ et pas avec le DMY4/.

Je me suis dit que IDS pouvait utiliser les variables d'environnement LC_* ou encore LANG. En effet elles étaient en fr_FR@euro, je les ai modifié en en_US comme ceci

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
27
28
29
30
31
32
33
$ locale
LANG=fr_FR@euro
LC_CTYPE="fr_FR@euro"
LC_NUMERIC="fr_FR@euro"
LC_TIME=fr_FR@euro
LC_COLLATE="fr_FR@euro"
LC_MONETARY="fr_FR@euro"
LC_MESSAGES="fr_FR@euro"
LC_PAPER="fr_FR@euro"
LC_NAME="fr_FR@euro"
LC_ADDRESS="fr_FR@euro"
LC_TELEPHONE="fr_FR@euro"
LC_MEASUREMENT="fr_FR@euro"
LC_IDENTIFICATION="fr_FR@euro"
LC_ALL=

$ export LC_ALL=en_US
$ locale
LANG=fr_FR@euro
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=en_US

Je relance le serveur mais là encore la tentative n'a pas aboutie. Avez une idée sur ce qui cloche dans cet import ? Besoin d'informations supplémentaires ?

PS : La table

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{ TABLE "informix".aep row size = 58 number of columns = 9 index size = 69 }
{ unload file name = aep.unl number of rows = 88 }

create table "informix".aep 
  (
    aepdemnum char(3) not null ,
    aepenfnum char(13) not null ,
    aepelenum smallint not null ,
    aepnum smallint not null ,
    aeptae char(10),
    aepdeb date,
    aepfin date,
    aepmda char(10),
    aepmva char(10),
    primary key (aepdemnum,aepenfnum,aepelenum,aepnum)  constraint "informix".pk_pae
  ) extent size 16 next size 16 lock mode row;
revoke all on "informix".aep from "public";

Les tuples

Code :

1
2
3
4
5
6
001|2005021000028|1|1|BTS|01/01/2006|01/01/2008|MUN| |
001|2005021000028|2|1|BTS|01/01/2006|01/01/2008|MUN| |
001|2005021000027|1|1|BTS|01/01/2006|01/01/2008|MUN| |
001|2005021000027|2|1|BTS|01/01/2006|01/01/2008|MUN| |
004|2005021000015|1|1|CCX|06/01/2007|12/31/2007|MUN|CCC| --> Pose problème celui là

Merci

[IFA2377]

Bonjour geekomono,

Bizarre ton histoire ! J'aurais bien vu un mois de 30 jours avec un jour à "31" ou un "O" à la place d'un zéro mais le fichier que tu proposes ne comporte pas ce cas de figure. N'y aurait-il pas une erreur sur l'item suivant que l'on ne voit pas ?

Je n'ai l'expérience que d'ISQL. Dans un tel cas, j'isolerais le problème en tentant un load sur cette table et je verrais bien sur quel item le load s'interromp. Je génèrerais une forme de cette table pour voir les items insérés et comment la table se comporte avec les dates.

Je ne connais pas ton environnement de travail mais tes variables ne sont-elles pas dans ton .profile ? Auquel cas, il n'est peut-être pas nécessaire de relancer ton serveur pour les prendre en compte. Il suffit d'actualiser tes nouvelles variables par :

$ . .profile

Cela n'a rien à voir mais ayant déjà vu ailleurs des noms de colonnes préfixés par le nom de leur table, je n'en ai jamais compris l'utilité. Pour ma culture, car je ne pratique plus, quel est l'intérêt de cette façon de travailler ?

[blackstreet]

Bonjour,

Logiquement, avec ce que t'a fais, ça devrait marché, car il suffit de positionner la variable d'environnement DBDATE à MDY4/ et ça devrait aller.

Bon, ce que je conseille, c'est de vérifier la prise en compte de la variable d'environnement après export.

Code :

1
2
3
 
export DBDATE=MDY4/
echo $DBDATE

Juste pour s'assurer que c'est bien pris en compte.

[geekomono]

C'est bon j'ai trouvé l'erreur. Le dbimport était lancé dans un script shell. Et une fameuse ligne de script comportait export DBDATE=DMY4/ . Plus de problème. suis confus.

Cela n'a rien à voir mais ayant déjà vu ailleurs des noms de colonnes préfixés par le nom de leur table, je n'en ai jamais compris l'utilité. Pour ma culture, car je ne pratique plus, quel est l'intérêt de cette façon de travailler ?

Moi même je ne sais pas. Peut être est ce créé par la commande dbexport.

Résolu.