IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Informix Discussion :

Locale utilisée lors d'un import de données avec dbimport


Sujet :

Informix

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    36
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 36
    Points : 32
    Points
    32
    Par défaut Locale utilisée lors d'un import de données avec dbimport
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : 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
    $ 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 : 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
    { 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  2. #2
    Invité
    Invité(e)
    Par défaut
    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 ?

  3. #3
    Membre averti Avatar de blackstreet
    Inscrit en
    Avril 2004
    Messages
    304
    Détails du profil
    Informations forums :
    Inscription : Avril 2004
    Messages : 304
    Points : 335
    Points
    335
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    export DBDATE=MDY4/
    echo $DBDATE
    Juste pour s'assurer que c'est bien pris en compte.

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    36
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 36
    Points : 32
    Points
    32
    Par défaut
    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.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 0
    Dernier message: 02/02/2009, 21h05
  2. erreur lors de l'import de données
    Par benoitXV dans le forum PostgreSQL
    Réponses: 10
    Dernier message: 06/11/2008, 17h13
  3. Problème lors de l'import de données
    Par UmutFB dans le forum VB.NET
    Réponses: 0
    Dernier message: 07/08/2008, 11h56
  4. Problème bizarre lors d'une importation de donnée [SSIS]
    Par caballero dans le forum MS SQL Server
    Réponses: 5
    Dernier message: 06/07/2007, 17h18
  5. erreur sql 1062 lors de l'import de données
    Par phebus29 dans le forum HyperFileSQL
    Réponses: 1
    Dernier message: 23/06/2006, 20h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo