[VxiR2] SQL d'un document multi requête

[Geo55]

Bonjour à tous,

J'ai un document composé de 3 requêtes qui sort des résultats faux sous webi. Le document fusionne 3 dimensions communes aux 3 requêtes qui est le numéro de commande.

J'aimerais comprendre pourquoi en analysant le SQL généré mais je ne sais pas comment fonctionne l'execution des requêtes lorsqu'il y en a plusieurs...

Concrètement comment ça se passe au niveau SQL, est-ce que BO lance les 3 requêtes les unes après les autres ? Comment la fusion des dimensions est-elle prise en compte au niveau SQL ? Les requêtes SQL sont-elles concaténées ?

Merci d'avance n'hésitez pas à me demander je ne suis peut-être pas assez claire et surtout pas spécialiste en SQL

[djam21]

Envoyé par Geo55

Bonjour à tous,

J'ai un document composé de 3 requêtes qui sort des résultats faux sous webi. Le document fusionne 3 dimensions communes aux 3 requêtes qui est le numéro de commande.

J'aimerais comprendre pourquoi en analysant le SQL généré mais je ne sais pas comment fonctionne l'execution des requêtes lorsqu'il y en a plusieurs...

Concrètement comment ça se passe au niveau SQL, est-ce que BO lance les 3 requêtes les unes après les autres ? Comment la fusion des dimensions est-elle prise en compte au niveau SQL ? Les requêtes SQL sont-elles concaténées ?

Merci d'avance n'hésitez pas à me demander je ne suis peut-être pas assez claire et surtout pas spécialiste en SQL

1. Il exécute les requêtes les unes après les autres.
2. Au niveau SQL, la fusion n'apparait pas ==> il n'y a rien. Tout ce fait au niveau du doc avec les données rapatriées
3. Rien de tout çà. Elles sont indépendantes.

[Geo55]

Merci à toi djam21 !

Donc en résumé, pour l'analyse du problème, je dois regarder les requêtes et les jointures les unes après les autres ?

[djam21]

Dsl pour le temps de réponse...

Pour trouver d'où vient ton pb, il faut analyser chacune de tes requetes.

Tu compare ce qu'elle ramène avec ce que tu attends.

S'il y a un écart, c'est que le SQL généré n'est pas correct. Là il te faudra modifier certaines choses dans l'univers. Trouve toi un jeu de données restreins çà sera plus simple.

A ta dispo si besoin...

[Geo55]

Merci pour ta réponse. T'inquietes pas c'est déjà bien de répondre je me doute que tu es occupé c'est bien normal

Le problème c'est que j'ai essayé "d'assembler" mes 3 requêtes en une seule pour la debugger sur SQL Developer, mais je ne sais pas si c'est correct

En fait je ne sais pas si c'est correct par rapport à ce que BO execute lorsqu'il créé son rapport.

Par exemple, la requete sort des commandes avec un statut, un pays de livraison, un montant et un cout de frais de port. Notre ERP va jusqu'au détail de la ligne de commande. Lorsque j'execute mon rapport sous BO, il regroupe toutes les lignes de commande en une seule commande, alors que sous SQL Developer, lorsque je lance la requête, il me détaille les lignes de commande.

Donc je ne suis pas sure que la requête soit juste... Comment savoir ce que BO execute réellement en SQL lorsqu'il fusionne 3 requêtes d'un même univers ?

[Geo55]

En fait pour reproduire en SQL ce que fait BO lors de l'execution d'un document multi requête, je crois qu'il faut utiliser l'opérateur UNION entre les requêtes..

[djam21]

Envoyé par Geo55

En fait pour reproduire en SQL ce que fait BO lors de l'execution d'un document multi requête, je crois qu'il faut utiliser l'opérateur UNION entre les requêtes..

Oui c'est un union, mais uniquement sur l'objet commun...

BO récupère les données sous la même forme que ton SQL.

C'est juste que toi, au niveau du TB de ton état, tu n'affiche pas le niveau de détail le plus fin...

[djam21]

Pour comparer c'est simple...

Tu n'affiche dans BO qu' un statut, un pays de livraison, un montant et un cout de frais de port.

Fais de même dans ton SQL.
==> SELECT statut, pays de livraison, montant, cout de frais de port
...
GROUP BY statut, pays de livraison

Fais attention pour tes indicateurs montant et cout de frais de port : mets la bonne fonction d'aggrégation...

[Geo55]

A vrai dire j'affiche bien plus d'informations que ça. Ce que j'ai cité c'était pour faire simple.

Ce qui est dommage est qu'on ne puisse pas voir le SQL généré par les 3 requêtes dans BO... Je me demande bien comment font ceux qui ont besoin de trouver un problème de données dans un document multi requetes.

A quoi sert le GROUP BY ici ? Je ne souhaite pas faire de l'aggrégation sur les indicateurs.

[Geo55]

En réalité je ne crois pas qu'il fasse un UNION après les essais que j'ai fait. En fait je ne sais pas du tout ce qu'il fait

[djam21]

Envoyé par Geo55

A vrai dire j'affiche bien plus d'informations que ça. Ce que j'ai cité c'était pour faire simple.

Ce qui est dommage est qu'on ne puisse pas voir le SQL généré par les 3 requêtes dans BO... Je me demande bien comment font ceux qui ont besoin de trouver un problème de données dans un document multi requetes.

A quoi sert le GROUP BY ici ? Je ne souhaite pas faire de l'aggrégation sur les indicateurs.

Tu peux voir le SQL généré par requête... Il existe une icone "SQL" quand tu édite tes fournisseurs de données...

Le SQL généré par BO contient certainement un GROUP BY... si tu as au moins 1 indicateur à rapatrier...

[Geo55]

Bonjour Djam21,

Merci encore pour ta participation. Oui je connais ce bouton SQL et d'ailleurs je l'utilise pour débugger mes requêtes. Cependant j'aimerais justement qu'il m'affiche le SQL des 3 requêtes combinées, et non pas d'une seule à chaque fois.

Ca peut paraitre stupide pour certains, mais au moins on verrait mieux comment il va récupérer les informations pour le document.

Et pour te répondre je n'ai pas de GROUP BY dans mes requêtes.

[Geo55]

Visiblement je pense que ce que je souhaite faire n'est pas possible, et je me dis qu'en fait celà n'a surement pas d'intérêt quand à la résolution de mon problème.

Mais il y a un début à tout Je pense que mon véritable problème est que je ne comprends pas bien ce qui se passe lorsqu'on fusionne 3 dimensions communes à 3 requêtes...

[djam21]

Envoyé par Geo55

Visiblement je pense que ce que je souhaite faire n'est pas possible, et je me dis qu'en fait celà n'a surement pas d'intérêt quand à la résolution de mon problème.

Mais il y a un début à tout Je pense que mon véritable problème est que je ne comprends pas bien ce qui se passe lorsqu'on fusionne 3 dimensions communes à 3 requêtes...

Requete 1 : SELECT A, B FROM TABLE
Requete 2 : SELECT A, C FROM TABLE

Quand tu rafraichis ton état, BO lance chacune des requêtes séparément.

Puis au niveau de l'état tu lie A de la requete 1 avec A de la requete 2.
Ce qui te permet d'afficher le tableau : A | B | C

Dans le cas contraire, tu aurais une incompatibilité...

[Geo55]

Merci djam21 je vois ce que tu veux dire.

Pour expliquer mieux ce à quoi je voulais aboutir en fusionnant sous BO :

Dans une première requête, nous avions une liste de numéro de commandes et le montant qu'on les avait facturé répondant à certain critère : elle devait être facturé sur la période de juin 2011.

Dans la seconde requête, nous avions une liste de commandes d'un certain type, ayant des frais de port, avec le montant de ces frais et le coût de ces frais.

Dans la troisième, nous avions une liste de numéro de commande d'un certain type, ayant des frais, avec le montant total de la commande.

En fusionnant sous BO, nous voulions récupérer les commandes qui étaient communes aux 3 requêtes.

A partir de là nous générons un état permettant de calculé le port que l'on avait facturé par commande sur une période donnée.

Cependant, BO nous rapportaient toutes les commandes des 3 requêtes, et non pas uniquement celle qui était commune aux 3 requêtes.

Résultat : dans l'urgence de délivré notre état à notre utilisateur, nous avons opté pour la fonction RECHERCHEV d'Excel afin de retrouver les commandes qui étaient présentes à la fois dans la requête 1, 2 et 3.

Mais bon ce n'est qu'une solution temporaire. Mais nous ne savons toujours pas pourquoi BO n'a pas fusionné...

[djam21]

Envoyé par Geo55

Merci djam21 je vois ce que tu veux dire.

Pour expliquer mieux ce à quoi je voulais aboutir en fusionnant sous BO :

Dans une première requête, nous avions une liste de numéro de commandes et le montant qu'on les avait facturé répondant à certain critère : elle devait être facturé sur la période de juin 2011.

Dans la seconde requête, nous avions une liste de commandes d'un certain type, ayant des frais de port, avec le montant de ces frais et le coût de ces frais.

Dans la troisième, nous avions une liste de numéro de commande d'un certain type, ayant des frais, avec le montant total de la commande.

En fusionnant sous BO, nous voulions récupérer les commandes qui étaient communes aux 3 requêtes.

A partir de là nous générons un état permettant de calculé le port que l'on avait facturé par commande sur une période donnée.

Cependant, BO nous rapportaient toutes les commandes des 3 requêtes, et non pas uniquement celle qui était commune aux 3 requêtes.

Résultat : dans l'urgence de délivré notre état à notre utilisateur, nous avons opté pour la fonction RECHERCHEV d'Excel afin de retrouver les commandes qui étaient présentes à la fois dans la requête 1, 2 et 3.

Mais bon ce n'est qu'une solution temporaire. Mais nous ne savons toujours pas pourquoi BO n'a pas fusionné...

Ahhhh.... je vois mieux ton pb...

Utilise des filtres sur les indicateurs en fonction de tes besoins...

Par exemple : [PORT] non nul

Côté requete tu ne pourra pas faire qq chose de simple... Le plus simple c'est des filtres...

[djam21]

Envoyé par Geo55

Merci djam21 je vois ce que tu veux dire.

Pour expliquer mieux ce à quoi je voulais aboutir en fusionnant sous BO :

Dans une première requête, nous avions une liste de numéro de commandes et le montant qu'on les avait facturé répondant à certain critère : elle devait être facturé sur la période de juin 2011.

Dans la seconde requête, nous avions une liste de commandes d'un certain type, ayant des frais de port, avec le montant de ces frais et le coût de ces frais.

Dans la troisième, nous avions une liste de numéro de commande d'un certain type, ayant des frais, avec le montant total de la commande.

En fusionnant sous BO, nous voulions récupérer les commandes qui étaient communes aux 3 requêtes.

A partir de là nous générons un état permettant de calculé le port que l'on avait facturé par commande sur une période donnée.

Cependant, BO nous rapportaient toutes les commandes des 3 requêtes, et non pas uniquement celle qui était commune aux 3 requêtes.

Résultat : dans l'urgence de délivré notre état à notre utilisateur, nous avons opté pour la fonction RECHERCHEV d'Excel afin de retrouver les commandes qui étaient présentes à la fois dans la requête 1, 2 et 3.

Mais bon ce n'est qu'une solution temporaire. Mais nous ne savons toujours pas pourquoi BO n'a pas fusionné...

BO fusionne bien mais c'est un UNION pas un INTERSECT...

D'où toutes les commandes des 3 requetes qui apparaissent.

[Geo55]

Bonjour djam21,

Oui et d'ailleurs j'aurai du m'expliquer mieux dés le début, et sans fautes ! Elles me piquent les yeux quand je me relis...

La fusion et l'UNION ne sont pas deux notions différentes ? Car il y a une fonction dans WEBI qui permet d'ajouter une requête combinée, et là tu choisie si tu fais un UNION, INTERSECT ou MINUS. Cependant, je ne peux pas m'en servir car je n'ai pas le même nombre de colonnes dans chaque requête.

Donc en fait je dois simuler mon intersection pour récupérer ce qui m'intéresse avec des filtres ? Bon je sais pas si j'ai bien compris le truc mais je vais essayer de voir ça.

Merci du conseil

[Geo55]

En fait je viens de voir que j'avais exactement le même problème que leclerjp dans ce post :
http://www.developpez.net/forums/d10...on-dimensions/

Et je pense qu'une solution pourrais être celle proposée en 3ème position par Julien59 (dans ce même post). J'ai essayé mais sans succès...

J'ai fait une capture d'écran en pièce jointe pour que vous voyez où j'ai posé mes filtres, car je ne sais pas si c'est juste.

[Geo55]

Autre remarque : ma fusion s'effectue sur le n° de commande qui est commun au 3 requêtes.

Sur la première requête, le n° de commande est au format VARCHAR2 sur 200 caractères (j'ai fait un DESCRIBE sur la table concernée). Alors que sur les 2 autres, le n° de commande provient d'une même table, mais au format VARCHAR2 sur 12 caractères.
Pensez-vous que celà peut poser problème par rapport à la fusion ?

Merci d'avance