Précédent   Forum des professionnels en informatique > Logiciels > Solutions d'entreprise > Business Intelligence > ETL
ETL Le Forum d'entraide ETL (Extract Transform Load) et Datawarehouse : DataStage, SunOpsis, Data Integrator, Informatica, OWB, Data Manager, Talend Open Studio,...
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 25/06/2008, 12h45   #1
Candidat au titre de Membre du Club
 
Inscription : avril 2005
Messages : 43
Détails du profil
Informations forums :
Inscription : avril 2005
Messages : 43
Points : 11
Points : 11
Par défaut [BO Data Integrator] Erreur de format

Bonjour,

Ca fait 2 jours que je me traîne un problème sur un de mes jobs sous BODI, et là je commence à en avoir marre car il n'y a rien de cohérent dans tout ça.
Petite précision, mon système marchait avant sur la 6.1 mais depuis que j'ai migré sur la XI je me retrouve avec des erreurs dans un de mes champ.

Voilà mon problème :
j'ai une table A dans laquelle on trouve :
  • ID_JRN -> la date du jour format DD/MM/YYYY
  • ID_HRE -> l'heure du jour GMT au format HH:MI
  • ID_HRE_05M -> les tranches horaires de 5min initialisées ici à NULL

Le but de mon Data Flow est de remplir mon champ ID_HRE_05M dans la table cible B, qui a la même structure que la table A, en plusieurs étapes :
  1. Je mappe mon ID_JRN avec le calcul suvant :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    ifthenelse(
        (
            (concat_date_time(Query.ID_JRN, to_date(Query.ID_HRE, 'HH24:MI')) >= TR_DWH_SPA_ANN.DEB_DAT_ETE) 
            AND
            (concat_date_time(Query.ID_JRN, to_date(Query.ID_HRE, 'HH24:MI')) <= TR_DWH_SPA_ANN.FIN_DAT_ETE)
        ), 
        (concat_date_time(Query.ID_JRN, to_date(Query.ID_HRE, 'HH24:MI')) + num_to_interval(2, 'H')), 
        (concat_date_time(Query.ID_JRN, to_date(Query.ID_HRE, 'HH24:MI')) + num_to_interval(1, 'H'))
    )
    Cela me permet, dans un premier temps, de concaténer DATE et HEURE dans ID_JRN qui est maintenant un DATETIME dans ma table B, puis dans un second temps de prendre en compte le décalage horaire entre les saisons d'hiver et d'été.

  2. Je mappe ID_HRE à partir de ID_JRN précédent pour avoir mon GMT+1 (+heure d'été ou non)
  3. Je remplis mon code tranche horaire 5M avec le calcul suivant

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    trunc(
        (
            (substr(Query_2.ID_HRE, 1, 2) * 12) 
            + 
            ((substr(Query_2.ID_HRE, 4, 2) / 5) + 1)
        ), 
        0
    )
    Je récupère de ce calcul un décimal, que je mappe avec une dernière query BODI en varchar(3).

Le souci c'est que mes données varchar en 3 caractère contiennent un '.' final pour les calculs sur 2 digits. Par exemple si le résultat du calcul précédent donne 92, j'aurais la chaîne '92.' dans mon champ !!

J'ai essayé de zappé les 2 premiers points de mon DF en prenant directement les heures ID_HRE de la table A (qui ne prennent donc pas en compte le décalage horaire) et je n'ai pas ce problème...

Que se passe-t-il donc ??

Merci d'avance pour votre aide
Ryo_san est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 25/06/2008, 18h45   #2
Membre éclairé
 
Homme
Consultant en Business Intelligence
Inscription : mai 2006
Messages : 276
Détails du profil
Informations personnelles :
Sexe : Homme
Âge : 29
Localisation : France

Informations professionnelles :
Activité : Consultant en Business Intelligence
Secteur : Conseil

Informations forums :
Inscription : mai 2006
Messages : 276
Points : 374
Points : 374
Bonjour, peux-tu donner quelques détails?

La fonction concat_date_time est une fonction de ton cru ou est-ce une fonction de BODI? (je n'ai pas accès à BODI pour vérifier qu'elle existe avant une bonne semaine...)

Quel est ton SGBD cible? source?

J'ai un doute sur ma compréhension de ta question, c'est les 3 champs de ton mapping qui posent problème ou c'est un seul des champs?

Les champs cibles sont en quel type?

Maintenant, le premier élément pour t'aider, mais c'est un peu de la triche, tu peux ajouter une Query supplémentaire, après la Query qui te pose problème, qui te fais un replace_substr() sur les champs problématiques et qui remplace tes '.' par du vide (''), par contre çà ne marchera qu'avec tes champs intermédiaires en chaines de caractères.
Prjprj est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 27/06/2008, 16h44   #3
Candidat au titre de Membre du Club
 
Inscription : avril 2005
Messages : 43
Détails du profil
Informations forums :
Inscription : avril 2005
Messages : 43
Points : 11
Points : 11
Salut Prjprj et merci de t'intéresser à mon problème...

Bon je préfère te dire d'ores et déjà que je pense que tu perds ton temps à essayer de résoudre ce problème, j'ai retourné la question dans tous les sens ces derniers jours, j'ai fais tous les tests possibles et imaginables sans le moindre succès.
J'ai donc repris tout le problème depuis sa source pour trouver un autre moyen d'alimenter ce champ.
Au final, je fais maintenant des jointures vers une autre table pour l'alimenter...

Mais bon si tu y tiens je peux te dire que ta méthode est l'une des premières que j'ai essayé et bien sur elle ne fonctionne pas. Si je reprend mon exemple de 92, tu auras avec cette méthode '920' à la place de '92.'
Pourquoi ? Certainement car la valeur en mémoire est 92.0 et que le fait de mettre une chaîne vide à la place ne fait que décaler le zéro vers la gauche...

Sinon pour répondre tout de même à tes questions voici quelques infos supplémentaire :

concat_date_time est une fonction native de BODI reconnue par Oracle qui est mon SGBD (cible et source).

Il n'y a qu'un seul champ qui me pose problème : ID_HRE_05M

Et pour le typage voilà comment ça se passe :
  • Dans la base de donnée cible, c'est un VARCHAR2(3)
  • Dans la dernière querry je le parse en varchar(3) évidemment
  • Dans l'avant-dernière querry, celle qui contient le calcul et le trunc, le format est décimal 28

Donc on pourrait logiquement se dire que de rajouter une autre query à la fin où on fait le replace substring mais cette fois sur le varchar(3) et non à partir du décimal marcherait... Mais bon je ne me rappelle plus avoir testé cette solution (il me semble mais bon...).
Je verrais à l'occasion mais pour l'instant j'attend la mise en prod avant de changer mes données en base de test qui sont correctes pour l'instant grâce à ma solution de secours...

Merci !
Ryo_san est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 18h14.


 
 
 
 
Partenaires

Hébergement Web