[Vxi3] Rapport multi-requêtes avec fusion de dimensions et variables max [Résolu]

[Elsa1]

Salut les zens !

Je vous la fais la plus courte possible.

J'ai 2 requêtes, avec (évidemment) des objets incompatibles contextuellement parlant. Je fusionne les dimensions "Codes personnes".
Jusqu'ici pas de problème.

La requête S me donne 29 personnes, alors que la C n'en donne qu'1.
Comment faire pour obtenir un rapport contenant les 29 lignes de résultat, et des colonnes vides pour les 28 n'apparaissant pas dans C ?

De ce que j'ai compris, je ne pourrai afficher des objets d'une des 2 requêtes qu'en créant des indicateurs, de type "max" ou "if".
Le souci, c'est que je voudrais plusieurs lignes par personne.

Ma requête S est censée me renvoyer, pour DUPONT (code = 622):

Code :

1
2
3
622 DUPONT alpha 125
622 DUPONT alpha 270
622 DUPONT beta 270

La requête C, elle, me donne des infos de type "fixe":

Code :

622 DUPONT   Jean    H    38

Comment afficher les 3 lignes alors que ces infos sont toutes des

Code :

1
2
max(valeur) où libellé=[catégorie]
max(valeur) où libellé=[montant]

Merci beaucoup d'avance !
Je continue à chercher de mon côté, évidemment...

[schkrumble]

Tu n'est pas obligée de créer des indicateurs, tu peux créer des informations :

La solution consiste à créer une variable de type "information" rattaché à la dimension fusionnée, et dont la formule te ramène les info issu de ta deuxième requête par un simple "égal" (nul besoin de Max ou de If)

Tu peux alors rajouter cette information dans le tableau qui contient tous les champs issu de ta première requête.

[Elsa1]

Merci pour ta réponse, mais les "max" sont obligatoires dans la mesure où ma BdD est faite de telle sorte qu'il y a plusieurs entrées de chaque champ.
Sans le max j'ai un #MULTIVALUES qui débarque !

Donc une information simple devient automatiquement un indicateur, ce qui ne pose pas tant de problèmes, en dehors d'un grand nombre de variables à créer...

En revanche, je reste avec mon unique ligne dans le rapport...
Je n'arrive pas à lui faire rapatrier une union, il me prend l'intersection des 2 requêtes.

Une idée ?

[Elsa1]

Alors, après moult recherches, j'ai touvé comment tout afficher, même les lignes pour lesquelles la requête C ne donne rien:
il faut aller dans les propriétés du rapport et cocher "Afficher lignes avec des valeurs de dimension vides".

En revanche, mon résultat est à présent sous la forme:

Code :

1
2
3
618
622 M DUPONT Jean  alpha 270
637

c'est-à-dire que, non seulement, je n'ai qu'une ligne pour la personne de la requête C, mais en plus, pour les autres, je ne peux obtenir aucune info de la requête S....
Si je remplace mes données par celles de la requête S (nom, prénom), j'ai un #SYNCDONNEES et un problème de contexte...

Comment faire ?

[Elsa1]

(j'ai un peu le sentiment de parler toute seule, mais bon... )

Alors c'est bon, c'est réglé pour afficher les infos communes aux 2 requêtes.
Par contre, en résumant ma compréhension de l'affaire, ce qu'on peut afficher c'est:
- les dimensions fusionnées
- au choix, les infos de la requête C (par exemple)
- pour la requête S, des infos transformées en variables

(ou réciproquement, des infos de S, et des variables construites à partir de C)

J'ai opté pour la 1ère méthode.
J'ai bien mes 30 personnes affichées, avec les infos en commun, les infos de la requête C (1 seule personne en dispose), et les infos de la req.S (30 lignes, pour 30 personnes).
En exécutant seulement la req.S, j'ai, pour ces mêmes 30 personnes, 70 lignes.

Question:Comment les afficher, alors que les infos spécifiques à S sont toutes des variables (de type max(valeur)) pour éviter les #MULTIVALUES ?

[Elsa1]

J'ai trouvé.
En fait, c'est assez logique, mais j'avais en partie la flemme de tout refaire: il faut se baser sur la requête qui a le plus de lignes.

Pour être claire, en reprenant ce que je disais:

Par contre, en résumant ma compréhension de l'affaire, ce qu'on peut afficher c'est:
- les dimensions fusionnées
- au choix, les infos de la requête C (par exemple)
- pour la requête S, des infos transformées en variables

(ou réciproquement, des infos de S, et des variables construites à partir de C)

ben... c'est la 2ème possibilité qui marche.

Je peux afficher la même info (ou variable) sur chaque ligne issue d'une requête S, mais je ne peux pas dédoubler l'unique ligne issue d'une requête C.
Bref... merci pour cet espace d'expression...

[Elsa1]

Re-tout le monde !

Alors, pour arranger les choses, j'ai ajouté une 3ème requête, notons-la R.

Cette requête est excatement la même que S, sauf qu'elle va chercher une autre catégorie d'objets.
Là où S récupère les lignes pour lesquelles le titre est A ou B, R va chercher les mêmes dossiers, pour les mêmes personnes, mais seulement les lignes dont le titre est C ou D.

(un dossier est fait de lignes de type A et/ou B, puis C et D)

Comme je souhaite mettre en rapport C et D avec A (ou B), j'ai fusionné les 2 requêtes sur le code du dossier.
Puis j'ai traduit tous les objets de R en indicateurs, pour les intégrer au rapport.
L'ennui est que le lien entre, disons A et C, est un lien lié aux propriétés mêmes des objets.
Par exemple, j'essaie de taper à la base et de rapatrier l'id de la ligne en question (pour vérifier que j'ai bien les bonnes infos).

Mon code ressemble à:

Code :

toto = Max([R_ligne_id]) Where (([S].[Ligne - Date]=[R_Date_notif]) AND ([S].[nom]=[R_nom]))

Mais ça ne me récupère que le max de l'id de tous les dossiers retrouvés, et pas du tout un pour chaque ligne.
Par contre si j'enlève le max, j'ai un MULTIVALUES qui débarque.

Une idée ?
Si ça manque de clarté, n'hésitez pas à me le dire, j'essaierai d'être plus compréhensible.

[TomDuBouchon]

Bonjour,

Désolé je débarque donc je reprends depuis le message initial.
Et j'ai du coup déjà une question : Je ne comprends pas le coup de tes max() pour palier du #MULTIVALUES. Où as-tu des multi-valeurs ?
N'y aurait-il pas un problème de base dans ta requête ?

Car ce que proposait schkrumble, à savoir créer des informations sur ta deuxième requête pour pouvoir rapatrier les informations dans un seul tableau me semble effectivement la bonne.

[Elsa1]

Oui tout à fait !
La méthode de schkrumble a bien fonctionné.

Avec mes 2 requêtes S et C, tout roule.
C'est la requête R que je ne sais pas gérer cette fois, donc vraiment seulement le problème exposé dans mon dernier message.

Du coup, pas grave si t'as "raté le début" !

[TomDuBouchon]

Une nouvelle fois désolé, mais cette fois parce que je ne comprends vraiment pas le problème.

J'essaie de résumer :

Tu as une requête A qui représente les informations de base.
Tu as une requête B qui récupère des données supplémentaires.
Tu as maintenant une requête C qui récupère de nouvelles données supplémentaires.
Jusqu'ici tout va bien.

Ensuite, pour pouvoir mettre les informations de B dans le même tableau que les informations de A, tu as été obligée de créer des variables à partir des dimensions de B. OK, ça va toujours.

Par contre, concernant la requête C, je ne vois pas ce qui t'empêche de faire la même manip que pour B.

Et je ne comprends toujours pas pourquoi tu utilises des max()... Car dans le cas que tu présentes, tu ne devrais jamais avoir de #MULTIVALUES.

[Elsa1]

Tu as bien compris la situation.
Mais ce que j'ai du mal à expliquer, c'est que la requête R récupère des données supplémentaires, mais de même nature exactement que S.

En fait c'est comme si je scindais les infos de S en 2 groupes.

Ma base est faite de dossiers, subdivisés en étapes, puis en attributs et enfin en valeurs.
S récupère des dossiers pour un type de demande, pour 2 étapes.
C récupère des infos sur les personnes demandeuses (donc un autre type de dossiers).
J'ai créé R pour faire correspondre aux 2 étapes de S 2 autres étapes.

Mes dossiers pour cette aide se présentent usuellement sous la forme:
étape A
étape B
étape C
étape D

Je voudrais avoir
A C
B D
sauf que je dois "expliquer" à BO selon quels critères faire ces liens (cf mon code ci-dessus).

Le #MULTIVALUES vient du fait que A, B, C et D sont de même nature, j'imagine. Pour un même dossier, l'étape peut être l'une des 4.

C'est plus clair, ou toujours pas ?

[TomDuBouchon]

Euh... Comment sont faites tes tables en fait ? parce que là je ne comprends vraiment mais alors vraiment pas...

Ma base est faite de dossiers, subdivisés en étapes, puis en attributs et enfin en valeurs.

Ca, ça va.

S récupère des dossiers pour un type de demande, pour 2 étapes.
C récupère des infos sur les personnes demandeuses (donc un autre type de dossiers).

Là je ne comprends plus.
Où se place le type de demande dans ta hiérarchie Dossier/Etapes/Attributs/Valeurs ?
Et donc les informations relatives à un élément commun (non précisé) sont sur plusieurs dossiers ?

Plus ça va plus j'ai l'impression que ta base est construite à l'envers, tu n'as que des lignes en fait ? Dossier/Etapes/Attributs/Valeurs sont les noms de tes colonnes ?

[Elsa1]

Oui la base a été construite étrangement, mais tu sais ce que c'est: on fait avec ce qu'on trouve en arrivant hein...
Et bien sûr pas de modif possible. Bref !

Donc oui ma structure est bien: Dossier/Etapes/Attributs/Valeurs.
Et le niveau supérieur au dossier c'est le type de demandes.

La requête "C" se fait au niveau d'un autre type, disons "informations générales mais indiscrètes", et j'y vais récupérer un dossier qui comporte l'adressse, le téléphone, les mensurations, le code de CB de chaque usager (d'où la fusion sur l'id de l'usager), etc...

Les requêtes "S" et "R" vont chercher, pour ces mêmes usagers, un autre type de demandes, disons dossiers d'inscriptions à des concours.
Ces dossiers sont structurés en étapes:
A- présentation d'un dossier bleu (pour le concours d'apnée)
B- présentation d'un dossier vert (pour le concours de calembours et charades)
C- délivrance d'une médaille
D- délivrance d'une coupe

Je voudrais faire correspondre A et/ou B avec C et/ou D.
Mais ces 4 objets sont de même nature: ce sont des étapes d'un dossier de type de demande.
Tu vois ?

P.S: je sais c'est un scandale mais je ne suis pas là la semaine prochaine.
Mais je reviendrai !
Et merci de te pencher sur mon problème.

[Elsa1]

Pour info, j'ai contourné le problème en ajoutant un attribut permettant de lier les événements.
Je mets donc ce post en RESOLU.