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

[#1]

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.

[#2]

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

[#3]

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

[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

[#5]

Bonjour

Merci pour vos réponses. Effectivement vous avez raison il suffit de mentionner systematiquement NoConcatenate et ça fonctionne parfaitement bien.

C'est un "probleme" recurrent avec Qlikview qui propose des automatismes très pratiques mais qu'il faut parfois contourner

Cordialement

jerome