[BO XIR2] Problème avec une jointure externe [Résolu]

[Fouinto]

Bonjour,

Afin de contourner un problème de jointure externe multiple, j'ai créé dans mon univers une table dérivée DERIVEE (cette table dérivée étant définie par un SELECT sur une poignée de table).
Bien entendu, je me suis empressé de créer la jointure avec la table mère MERE en précisant bien que la jointure était externe.

J'ai bien quelque chose de la sorte :
- pour 1 ligne de MERE, j'ai 0 à n lignes de DERIVEE,
- pour 1 ligne de DERIVEE, j'ai 1 et 1 seule ligne de MERE.

Jusque là, pas de souci.

J'ai des objets (au sens de Designer) définis sur les champs de ces deux tables.

Jusque là, pas de souci.

Dans mon rapport WebI, je veux mettre une restriction sur un champ de DERIVEE (exemple : DERIVEE.type=42).

Et là, c'est le drame ! s'en est fini de ma jointure externe ! et pour cause, voici le code SQL qu'il me sort :

SELECT ...
FROM MERE, (SELECT ...) DERIVEE
WHERE ...
MERE.derivee=DERIVEE.ID(+)
DERIVEE.type=42;

WTF ?!? mon problème est facil à résoudre en SQL ! Soit je mets le "DERIVEE.type=42" dans ma sous requête définissant DERIVEE, sois je le
laisse où il est mais je mets je remplace "DERIVEE.type=42" par "DERIVEE.type(+)=42"
mais comment je peux faire dans Designer pour qu'il me génère le code SQL que je veux dans ce cas de figure ?

Quelqu'un a une idée (ou une piste de réflexion) ?

merci pour votre aide

Fouinto

[Julien59]

Il n'y a pas de solution.
Il est normal que ta jointure externe ne fonctionne plus comme tu l'as expliqué.
Pour contourner ton problème, je te conseille de passer par des filtres prédéfinis.

Code :

DERIVEE.type(+)=@prompt('quel type?','A',,mono,,)

Ca devrait fonctionner.

Bon courage

[Fouinto]

Envoyé par Julien59

Il n'y a pas de solution.
Il est normal que ta jointure externe ne fonctionne plus comme tu l'as expliqué.
Pour contourner ton problème, je te conseille de passer par des filtres prédéfinis.

Code :

DERIVEE.type(+)=@prompt('quel type?','A',,mono,,)

Ca devrait fonctionner.

Bon courage

Merci pour votre réponse. C'est bien ce que je craignais
N'y-a-t-il aucune solution côté designer ?
En effet, le "type" est une donnée complètement "abstraite", par conséquent, l'utilisateur ne les connaît pas. De plus, j'ai plusieurs centaines (probablement millier) de type... je me vois mal faire une classe par type...
Si quelqu'un a une autre idée, je suis preneur...

[Julien59]

Je ne comprends pas ou est le problème.
En quoi ma solution ne répond pas au besoin ?
A moins que tu n'aies différents objets "type", dans ce cas, je dis ok, mais je ne l'ai pas compris comme ca.
J'ai compris qu'il y'avait différentes valeurs possibles, des milliers, dans ton objet "type".
Ai-je mal compris ?

Sinon, non, il n'y a pas de solution sous Designer pour que la jointure générée par le designer, lors de la mise en place d'un filtre, soit externe.

[Fouinto]

Envoyé par Julien59

Je ne comprends pas ou est le problème.
En quoi ma solution ne répond pas au besoin ?
A moins que tu n'aies différents objets "type", dans ce cas, je dis ok, mais je ne l'ai pas compris comme ca.
J'ai compris qu'il y'avait différentes valeurs possibles, des milliers, dans ton objet "type".
Ai-je mal compris ?

Sinon, non, il n'y a pas de solution sous Designer pour que la jointure générée par le designer, lors de la mise en place d'un filtre, soit externe.

Bon, c'est surement moi qui m'exprime mal et/ou qui n'ai pas bien compris ta solution.

Alors voila ce que j'ai fais pour tester ta solution (je ne connaissais pas la commande @prompt) : j'ai créé une "condition" depuis designer dans laquelle j'ai renseigné ton code (Si d'autres veulent tester la commande prompt, il manque 2 virgules à la fin de l'exemple )

J'utilise donc cette "condition" dans les filtres de ma requête depuis WebI, et lorsque je la rafraichi, j'ai une fenêtre qui s'ouvre me demandant 'quel type?'.
Je confirme que si je saisis 42 dans cette fenêtre, j'obtiens bien le résultat attendu !
Mon problème se trouve justement dans cette fenêtre/question, car moi, je sais qu'il faut mettre 42 pour cette requête mais pas les utilisateurs qui vont devoir la rafraichir ! Et puis ça va m'obliger à mettre cette fenêtre dans plein de rapports avec des valeurs différentes suivant les rapports...

Voila pourquoi je cherchais une autre solution... mais je m'y suis peut-être mal pris !

Quelques précisions :
si j'arrive à trouver une solution à ce problème je vais pouvoir diviser par 2 à 5 le nombre de fournisseurs de données dans une 50aine de requêtes existantes.
En effet, à ce jour, l'univers ne tient pas compte du fait que cette donnée est optionnelle, et à chaque fois qu'on en a besoin dans un rapport, on s'en sort en faisant un fournisseur spécifique pour la récupérer c'est pratique quand on en a 4 à 5 dans un rapport (surtout au niveau maintenance )

[Julien59]

Si je comprends bien, tu veux juste placer un filtre dans les requêtes de différents états et que les utilisateurs n'aient pas accès à ce filtre ?
Je vois 3 solutions du coup :
1/ Le SQL personnalisé : sûr de fonctionner, mais je n'aime jamais le SQL personnalisé...
2/ Si tu ne veux absolument pas d'invite, il faut que tu crées autant de filtres prédéfinis que nécessaires, et que tu les mettes 1 par 1 dans tes états.
3/ Mettre dans le filtre de requête :

Code :

1
2
DERIVEE.type = 42 OR
DERIVEE.type IS NULL

A priori, tu devras dans tous les cas repasser sur tous tes états, donc à part la solution 1 que je n'aime pas, la 2 et la 3 se valent. La 2 te "polluera" ton univers, mais elle sera plus facile à maintenir. A toi de voir
La solution de l'invite est pour moi la meilleure.
Surtout si tu es en SP3 => Possibilité d'affecter une valeur par défaut + Possibilité de mettre une invite en facultative

Bon courage

[Fouinto]

Envoyé par Julien59

Si je comprends bien, tu veux juste placer un filtre dans les requêtes de différents états et que les utilisateurs n'aient pas accès à ce filtre ?

Si ce que tu appelles les utilisateurs sont les "rafraichisseurs" alors oui.

Envoyé par Julien59

Je vois 3 solutions du coup :
1/ Le SQL personnalisé : sûr de fonctionner, mais je n'aime jamais le SQL personnalisé...
2/ Si tu ne veux absolument pas d'invite, il faut que tu crées autant de filtres prédéfinis que nécessaires, et que tu les mettes 1 par 1 dans tes états.
3/ Mettre dans le filtre de requête :

Code :

A priori, tu devras dans tous les cas repasser sur tous tes états, donc à part la solution 1 que je n'aime pas, la 2 et la 3 se valent. La 2 te "polluera" ton univers, mais elle sera plus facile à maintenir. A toi de voir
La solution de l'invite est pour moi la meilleure.
Surtout si tu es en SP3 => Possibilité d'affecter une valeur par défaut + Possibilité de mettre une invite en facultative

Bon courage

Je voulais éviter la solution 1/ pour des raisons de maintenance . Quand aux solutions 2/ et 3/ ça peut le faire pour une ou deux requêtes, mais polluer mon univers (qui est déjà plutôt complexe) avec des filtres prédéfinis qui ne sont utilisés que dans une requête, je vais me faire tuer par mes collègues

Je vais donc probablement utiliser la dernière corde à mon arc : ne pas utiliser BO mais un outil intégré à l'applicatif.

En tout cas, merci beaucoup pour ton aide !