Discussion :

[hittony]

Bonjour,

Je viens de découvrir que selon l'ordre des choix des objets (Query Item), la requête générée peut varier ! Dans un sens, j'ai bel et bien 5 tables, dan l’autre, j'en ai une de trop.

Certes, je dois avouer que je n'ai pas parcouru toutes les requêtes (Query Subject) sur le chemin, j'ai fait sauter une table sur les cinq.

Mais ça ne m'empêche pas de vouloir connaitre les règles appliquées par Cognos.

L'avez-vous déjà vu et avez-vous des astuces ?

[matching_ds]

Pour mon cas, j’ai dans Framework un ordre bien précis de Query Item. J’ai ajouté des champs dans ma table dans la base de données que j’ai ajoutée également dans le Framework. Au moment de la génération de la requête, le champ est bel et bien à la fin de la requête.
Je ne sais pas si cela t’a aidé ???
Une chose que je n’ai pas comprise, c’est pourquoi tu parles de 5 tables d’un côté et de 6 de l’autre

[hittony]

Pour mon cas, j’ai dans Framework un ordre bien précis de Query Item.

Merci d'abord pour ta participation, je vais essayer de mieux expliquer mon pb:

Ce n'est pas l'ordre de Query Item défini dans le FWK qui me gène, c'est l’ordre du choix lors de test.

Ex.
Query Item = QI, Query Subject = QS
QI_1 de QS_1,
QI_2 de QS_2,
QI_3 de QS_3,
QI_4 de QS_4,
QI_5 de QS_5
(Il n'y a pas que ces 5 QS dans le FWK, bien entendu)

Joitures toujours en 1-n : QS_1 - QS_2 - QS_3 - QS_4 - QS_5

Si je pioche dans ce sens : QI_1 -> QI_3 -> QI_4 -> QI_5, la requête générée est from QS_1, QS_2, QS_3, QS_4, QS_5. C'est exactement ce que je voulais

Mais si je pioche dans le sens inverse : QI_5 -> QI_4 -> QI_3 -> QI_1, la requête générée est from QS_1, QS_2, QS_3, QS_4, QS_5, QS_6 (l'une de trop)

[matching_ds]

J’avoue que c’est quand même un peu bizarre, je n’ai pas cognos sous les yeux pour faire un test mais les jointures de types (1-n) me font penser à une éventuelle liaison avec les clés étrangères …. A vérifier !
quelqu'un d'autre pourra nous aider peut être ???