Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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.
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
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
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