4 Replies Latest reply: Apr 24, 2014 4:07 PM by Jerome GODARD RSS

    problème généré par l'instruction OUTER JOIN LOAD

      Je souhaite partager une petite expérience en espérant soit vous permettre de trouver une solution à un dysfonctionnement que je crois bien avoir identifié soit me permettre de comprendre comment je pourrait éviter le dysfonctionnement autrement qu'en employant la rustine que j'ai mis en place pour le résoudre.

       

      Voici ce que j'ai constaté:

       

      Lorsque je créer une table nominative via un premier LOAD classique puis un second avec un OUTER JOIN

      il arrive de manière incompréhensible que les tables créées ultérieurement aient de comportement erratiques.

      rien de tel qu'un petit exemple:

       

      // je créer une table nominatif avec l'instruction OUTER JOIN LOAD

      myJoinTable:

      LOAD

        field_1,

        field_2,

        field_3,

        field_4

      RESIDENT ActiveDataSet;

       

       

      OUTER JOIN LOAD

        field_1,

        field_2,

        field_3,

        field_5,

        field_6

      RESIDENT SourceFileData;

       

      // je créer une autre table qui n'a rien à voir, avec un autre nom

      myOtherTable

      LOAD

           field_A,

           fiald_B

      FROM ..... ;

       

      // je tente une intruction impliquant myOtherTable

       

      DROP TABLE myOtherTable;

       

      // =====> Message d'erreur pour l'instruction DROP TABLE m'indiquant que la table myOtherTable n'existe pas.

      // =====> ca peut être assez erratique car l'erreur ne vient pas nécessairement sur la table qui suit immédiatement.

       

      J'ai cherché quel pouvait être le probleme. En commentant toutes le instruction concernant myOtherTable j'ai eu des message d'erreur équivalant sur des instructions STORE ou LOAD RESIDENT impliquant d'autres table. J'ai failli abandonner et démissionner de mon poste…

       

      Puis a force d'éliminer toutes les tables provoquant de messages d'erreur je suis évidement remonté jusqu' à mon OUTER JOIN. L'hypothèse est apparue que c'était peut-être elle le problème. J'ai donc tenté la solution suivante qui a fonctionné et je vous la recommande si vous êtes confronté à un problème similaire.

      // je créer une table TEMPORAIRE avec l'instruction OUTER JOIN LOAD

      TEMP:

      LOAD

        field_1,

        field_2,

        field_3,

        field_4

      RESIDENT ActiveDataSet;

       

       

      OUTER JOIN LOAD

        field_1,

        field_2,

        field_3,

        field_5,

        field_6

      RESIDENT SourceFileData;

       

      // Je charge IMMEDIATEMENT cette table dans une table nominative

      myJoinTable:

      LOAD * RESIDENT TEMP;

       

      // et je supprime AUSSITOT la table générée avec l'instruction OUTER JOIN

      DROP TABLE TEMP;

       

       

      // je n'ai plus de problème… enfin pas de problèmes inexplicables

       

      Bien sûr je ne suis pas à l'abris de ne pas avoir bien compris comment utiliser l'instruction OUTER JOIN. Si vous avez un conseil à me donner, surtout n'hésitez pas.

        • Re: problème généré par l'instruction OUTER JOIN LOAD
          christian juillard

          Jérôme,

           

          Ce que j'en déduis c'est que si la table n'exite pas elle a été automtiquement assimilée à la précédente (généralement par structure identique, dans ce cas QV ne tient pas compte du nom)

           

          Essayez

          Myothertalbe:

          NoConcatenate LOAD ... FROM ...

           

          pour tester si le pb est toujours existant

           

          Bon courage

          Christian

            • Re: problème généré par l'instruction OUTER JOIN LOAD

              Bonjour Christian,

               

              merci pour votre réponse et votre explication qui semble vraisemblable.

              De fait j'ai des champs similaire dans plusieurs tables car j'utilise beaucoup qlikview pour transformer les données avant de les exploiter ce qui implique souvent de les charger dans différentes tables. Le problème peut effectivement provenir de là.

              Mais alors il faudrait systématiquement utiliser NoConcatenate (je ne suis pas contre, mais c'est un peu lourd et incohérent avec le fait qu'en nommant une table on peut penser en toute logique qu'elle ira se charger de manière autonome)

              et surtout le problème n’apparaît que lorsqu'une table directement créée avec l'instruction de jointure existe ; le même contenu chargé dans un nouvelle table afin de supprimer celle de la jointure réglant le problème.

              Ce qui tendrait à signifier que l'instruction OUTER JOIN potentialise les jointures incontrôlées avec les tables chargées par la suite.


              J'y voit plutôt un BUG, de faible criticité une fois qu'il est identifié et que des solutions existent pour le contourner.

               

              Dés que j'aurais le temps je ferai plus de tests mais là il faut que je produise

               

              Jérôme

                • Re: problème généré par l'instruction OUTER JOIN LOAD
                  Brice SACCUCCI

                  Bonjour,

                   

                  par défaut, QlikView va toujours mettre dans une seule table les données qui ont exactement les mêmes colonnes. C'est équivalent à l'utilisation du mot-clé Concatenate et c'est aussi la raison d'être du mot clé NoConcatenate, lorsqu'il est nécessaire d'éviter ce comportement.

                   

                  On peut discuter du fait que cela soit intuitif ou pas, mais il ne s'agit pas d'un bug, et cela peut être utile quand on charge 100 fichiers ayant la même structure, mais des données correspondant à des périodes différentes, par exemple

                   

                  Voici le contenu du manuel correspondant :

                   

                  "

                  26.7 Concaténation de plusieurs tables en une

                   

                  Concaténation automatique

                   

                  Si les noms et le nombre de champs de plusieurs tables chargées sont exactement identiques, QlikView

                  concaténera automatiquement le contenu des différentes instructions en une seule table.

                   

                  Exemple :

                  load a, b, c from table1.csv;

                  load a, c, b from table2,csv;

                   

                  La table interne qui en résulte possède les champs a, b et c. Le nombre d'enregistrements correspond à la

                  somme des nombres d'enregistrements des tables 1 et 2.

                   

                  Règles :

                  l Le nombre et les noms des champs doivent être exactement identiques.

                  l L'ordre des deux instructions est arbitraire."

                   

                  Merci,

                  Brice