Discussion :

[FORMULARY]

Ca vient surtout des lignes concatenate (RSA) et concatenate (RUM).
Revoit ton script ....

[SteffieLili]

Ce sont mes tables de fait... Comment faire sans passer par concatenate et que ca me rentre tout bien dans la même table ? Et en quoi cela génèrerait-il une clé synthétique ? J'essaie de comprendre mais sérieusement je ne vois pas

[FORMULARY]

La table synthétique est créée car il y a plusieurs champs communs dans tes deux tables RSA et RUM.
D'où viennent les champs rsaCode etc... dans la table RUM ?
Normalement, le seul champ commun entre les tables doit être l'ID du RSA.

Question : Tu parles d'une année 1 et d'une année 2, et tes SQL ne font aucun where ????

[SteffieLili]

D'où viennent les champs rsaCode etc... dans la table RUM ?
Normalement, le seul champ commun entre les tables doit être l'ID du RSA.

Justement Formulary, il n'existe dans mon code qu'un seul champ commun à la table RSA et RUM qui est idRSA. Je ne comprends pas pourquoi les champs rsaEtab et rsaCode viennent s'ajouter à ma table RUM Il n'y a aucun champ nommé comme tel dans la table RUM

Tu parles d'une année 1 et d'une année 2, et tes SQL ne font aucun where ????

Alors effectivement, je pensais ne pas avoir besoin de where car à chaque année correspond une base de donnée distincte sous format access. je me connecte donc à deux bases de données pour deux années. Vous voyez ce que je veux dire ?

[PhunkyBob]

Si je résume, vous faites :

// Année 1
- Création d'une table "RSA" avec les champs A, B et C.
- Jointure sur cette table pour rajouter le champ D.
- Jointure sur cette table pour rajouter le champ E.

// Année 2
- Concaténation sur la table "RSA" des champs A, B et C.
--> comme les champs D et E ne sont pas spécifiés mais qu'on demande la concaténation à la table RSA, ceux-ci seront remplis à "vide".
- Jointure sur cette table pour rajouter le champ D. Sauf qu'il existe déjà, donc on fait une jointure sur toutes les lignes.
- Jointure sur cette table pour rajouter le champ E. Sauf qu'il existe déjà, donc on fait une jointure sur toutes les lignes.



Ce qu'il faut faire c'est :
- une table pour l'année 1
- qu'on enrichie
- une table pour l'année 2
- qu'on enrichie
- une concaténation du résultat de l'année 2 dans la table de l'année 1


Si l'enrichissement est le même pour l'année 1 et l'année 2 (même source), alors le plus simple, c'est de :
- faire une table pour l'année 1
- on y concatène l'année 2
- on enrichie le total

[SteffieLili]

Vous avez bien résumé PhunkyBob.

- une table pour l'année 1
- qu'on enrichie
- une table pour l'année 2
- qu'on enrichie
- une concaténation du résultat de l'année 2 dans la table de l'année 1

J'ai travaillé (et je travaille encore) sur la génération de fichiers plats QVD (un par table) pour justement en avoir un sur mon année 1, un sur mon année 2 et les concaténer sur un 3ème script Qlikview. Que pensez-vous de cette solution ?

[PhunkyBob]

Je pense qu'il est possible de tout faire dans le même script.


Concernant l'enrichissement, si celui-ci est stocké dans le QVD, êtes vous sur que d'une année à l'autre elles ne risquent pas de changer ?

[SteffieLili]

Le soucis de le faire dans le même script c'est qu'à terme il y aura autant d'années rajoutées que possible. Là je bosse sur de l'existant sur 3 ans, mais ensuite, il faudra que mon outil permette d'enrichir la base chaque année avec de nouvelles données. Cela ne risque pas d'être trop lourd à tourner ?
Les années changent un peu les unes par rapport aux autres oui mais une année finie est fixe. Elle ne changera jamais.
J'ai testé avec les fichiers plats et je n'y arrive pas du tout Cela me génère des table avec un champs codé en XML ...

Sinon, pour reprendre dans le même script, cela tourne sans générer d'erreur mais ma fenêtre de débogage ne veux plus se fermer.
Ce que j'ai fait :

--> LOAD de la table RSA et je l'ai enrichie avec mes "JOIN LOAD", idem pour la table RUM et DAS pour la première année.
--> LOAD de la table RSA que j'ai enrichie de la même manière et idem pour RUM et DAS pour la deuxième année.

--> Concaténation avec un concatenate de chaque table de l'année 2 dans celles de l'année 1.

C'est à cela que vous pensiez PhunkyBob ?

J'ai l'impression que ce script plante au final sans erreur générée

[PhunkyBob]

C'est à cela que vous pensiez PhunkyBob ?

Difficile à dire sans voir le code.

Si vous enregistrez tout dans des tables vraiment distinctes, oui.

Les années changent un peu les unes par rapport aux autres oui mais une année finie est fixe. Elle ne changera jamais.

Supposons que dans une table, vous ayez un identifiant d'une personne et que grâce à la jointure, vous récupériez son nom.
En 2008, l'identifiant "1" correspondait à "Mlle Machin".
Vous stockez ça dans un fichier plat, pour ne plus jamais avoir besoin de le recalculer.

En 2013, cette personne s'étant mariée, elle a changé de nom, (mais pas d'identifiant).
Vos données auront l'identifiant "1" correspondant à "Mme Bidule".

Si vous chargez vos 2 fichiers plats, alors vous aurez le même identifiant lié à 2 noms de personnes différentes.
Dans votre application QlikView, il sera difficile pour l'utilisateur de s'y retrouver...


Peut-être qu'il serait plus judicieux d'historiser uniquement les faits (qui contiennent des identifiants), de les charger depuis des fichiers plats tous dans une même table, puis de faire les jointures sur le résultat.


Mais encore une fois, tout dépend du besoin fonctionnel.

J'ai testé avec les fichiers plats et je n'y arrive pas du tout Cela me génère des table avec un champs codé en XML ...

Encore un problème qui n'a pas de rapport avec le sujet initial de ce fil

Je vous invite à ouvrir un nouveau fil sur ce sujet.