|
| Etat à partir d'une requete SQL n'affiche rien |
| Iniciado por pascal.beolet, 17,jul. 2020 15:03 - 11 respuestas |
| |
| | | |
|
| |
Miembro registrado
9 mensajes |
|
| Publicado el 17,julio 2020 - 15:03 |
Bonjour, j'ai crée une requête via l'éditeur de requête de Windev, sauf que j'ai du modifier le code SQL car j'avais besoin d'une condition calculée. Pour résumer la situation: Chaque client a des commandes, chaque commandes des lignes (avec une colonne "quantité") et chaque lignes des productions (avec une colonne "quantité reçue"). Ma requête consiste à afficher les lignes dont la quantité inscrite est supérieur à la somme des quantités reçues, donc les lignes qui n'ont pas été entièrement reçues. Jusque la ça va, la requête fonctionne parfaitement voici le code SQL:
SELECT
Clients.NomClient AS NomClient,
Commandes.NoCommande AS NoCommande,
Commandes.VosReference AS VosReference,
Lignes.NoLigne AS NoLigne,
Lignes.DateSouhaitee AS DateSouhaitee,
Lignes.Quantite AS Quantite,
SUM(Détail_Production.QteRecue) AS Somme_Recu,
Lignes.Obs AS Obs,
Lignes.NoReferenceComposant AS PieceProgrammee,
Pieces.Reference AS PieceVierge,
Lignes.NoLigneClient AS NoLigneClient
FROM
Pieces
RIGHT OUTER JOIN
(
(
(
Clients
INNER JOIN
Commandes
ON Clients.NoClient = Commandes.NoClient
)
INNER JOIN
Lignes
ON Commandes.NoCommande = Lignes.NoCommande
)
LEFT OUTER JOIN
Détail_Production
ON Lignes.NoLigne = Détail_Production.NoLigne
)
ON Pieces.NoPiece = Lignes.NoReferenceComposant
WHERE
(
Commandes.NoClient = {ParamNoClient}
AND Commandes.Soldee = 0
)
GROUP BY
Clients.NomClient,
Commandes.NoCommande,
Commandes.VosReference,
Lignes.NoLigne,
Lignes.DateSouhaitee,
Lignes.Quantite,
Lignes.Obs,
Lignes.NoReferenceComposant,
Pieces.Reference,
Lignes.NoLigneClient
HAVING SUM(Détail_Production.QteRecue) < Quantite OR SUM(Détail_Production.QteRecue) IS NULL
ORDER BY DateSouhaitee DESC
Je ne peux plus faire de retro analyse a cause de l'avant dernière ligne qui est indispensable.
Maintenant je veux créer un état, donc j'ai fait un état sans rupture et affiché toutes les informations de la requête sauf que rien ne s'affiche. J'ai essayé de créer un état avec rupture en sélectionnant "DateSouhaitee" comme tri mais même résultat:
"il n'y a pas de données à imprimer".
Merci pour votre aide. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
34 mensajes |
|
| Publicado el 17,julio 2020 - 16:07 |
Bonjour
Une solution de contournement essaie de stocké ton résultat dans une table mémoire invisible, et fait ton état a partir du champ table |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
9 mensajes |
|
| Publicado el 17,julio 2020 - 16:28 |
Bonjour,
l'idée est bonne, mais l'état ne veut tout simplement pas s'imprimer car il ne trouve aucune données à afficher. Je viens de tester une table dans une fenêtre remplie avec la requête et cela fonctionne, le problème vient donc de l'état. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
213 mensajes |
|
| Publicado el 17,julio 2020 - 16:30 |
Bonjour Pascal,
Une réponse en trois volets.
1) La requête elle-même...
right outer join, inner join, inner join, left outer join
Ça en fait des conditions potentielles à respecter...
Est-ce que tu as testé la requête hors de ton état ?
Est-ce qu'elle retourne des valeurs ?
2) Commandes.NoClient = {ParamNoClient}
J'assume que cette condition trouve sa valeur dans ton état.
Autrement...
3) Je ne peux plus faire de rétro analyse a cause de l'avant dernière ligne qui est indispensable.
En accord avec toi, Windev a peu de chances de pouvoir interpréter ta requête.
Mais ça ne veut pas dire que tu ne peux pas créer une requête pour autant.
Avec l'éditeur de requête.
Personnellement, je ne fais aucune rétro-analyse de mes requêtes.
Le rendu graphique que Windev en donne a peu de valeur à mes yeux.
C'est le code SQL qui m'intéresse, sa facilité de lecture entre autre.
Serge
--
-----
Parfois, la logique est implacable... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
213 mensajes |
|
| Publicado el 17,julio 2020 - 16:35 |
Une requête SQL que Windev ne comprend pas sous l'éditeur de requête.
Étape 1
Créer une requête toute simple avec l'éditeur de requête.
Par exemple un SELECT de NomClient depuis la base Clients.
Ok
Étape 2
Clique droit, Code SQL
Étape 3
Remplace le SELECT bidon par le vrai code SQL de ta requête.
Ajuster pour que ce soit cohérent et lisible, par exemple...
Étape 4
Lorsque satisfait, clique droit, rétro-analyse.
Ignorer (X) les ajustements que propose Windev, il ne comprend pas de toute façon.
Étape 5
Est-ce que Windev te propose deux blocs reliés entre eux ?
Celui du code SQL et celui du résultat ?
Tu as une requête potentiellement fonctionnelle.
Il n'y a plus qu'à tester.
À tester avec une requête que tu sais fonctionnelle pour débuter.
Il sera toujours tmeps de passer aux requêtes complexes.
Serge
--
-----
Parfois, la logique est implacable... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
213 mensajes |
|
| Publicado el 17,julio 2020 - 16:39 |
Un exemple de requête fonctionnelle sans la "rétro-analyse".
Bloc "Code SQL", bloc "Résultat".
Serge
--
-----
Parfois, la logique est implacable... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
9 mensajes |
|
| Publicado el 17,julio 2020 - 17:08 |
Bonjour , je vais répondre a vos questions dans l'ordre, j’avoue que j'ai du mal à vous suivre dans vos différents commentaires.
1) et 2) oui j'ai testé la requête avec différentes valeurs du paramètre {ParamNoClient} et tout fonctionne parfaitement
3) Je ne comprend pas pourquoi vous me proposez de créer une requête comme ça, la retro analyse ne fonctionne pas car j'utilise le HAVING que windev ne comprend pas, le problème est que l'état n'affiche rien alors que si je met la requête dans une table dans une fenêtre par exemple ça fonctionne parfaitement. Vous parlez d'ignorer les "ajustements" windev mais impossible de les ignorer.
4) Je vois votre exemple, mais dans ma situation il y a le "HAVING".
Je suis dans l'incompréhension. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
213 mensajes |
|
| Publicado el 17,julio 2020 - 17:37 |
Pascal,
Je viens de tester une table dans une fenêtre remplie avec la requête et cela fonctionne, le problème vient donc de l'état.
Tu répondais à ma question alors que j'écrivais ma réponse.
Difficile, de ce point, de dire ce qui pourrait accrocher dans l'état sans en voir les détails.
----------
Pour ce qui est de l'éditeur de requête, ce que je tente d'expliquer, c'est que MALGRÉ la présence du HAVING, tu peux l'utiliser.
Je le fais fréquemment.
Une requête qui n'a rien de complexe, mais qui contient un HAVING.
En fait, la requête peut contenir ce que tu voudras du moment que c'est "logique" pour SQL.
Windev ne peut l'interpréter, mais il me donne deux blocs reliés entre eux.
Celui du code SQL, celui du résultat.
Du coup, je peux tester et confirmer que c'est fonctionnel.
----------
Pourquoi passer par l'éditeur de requête?
Parce que tu pourras lier la requête à ton état de façon "naturelle" pour Windev.
Puis utiliser les fonctionnalités de l'état pour lister les données.
Mon point de vue, qui vaut tout autre.
Serge
--
-----
Parfois, la logique est implacable... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
213 mensajes |
|
| Publicado el 17,julio 2020 - 17:40 |
Sans oublier que ta requête est maintenant accessible par d'autres modules de ton application...
L'état, une gestion, etc...
Serge
--
-----
Parfois, la logique est implacable... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
9 mensajes |
|
| Publicado el 17,julio 2020 - 18:33 |
J'ai exactement comme vous, une boite SQL reliée à une boite résultat, je viens de résoudre le problème tout seul, le problème était le SUM() dans le HAVING, j'ai remplacé le SUM() par l'alias présent dans le SELECT et l'état fonctionne à présent.
Un bug ma fois qui m'aura couté la journée. Merci pour votre aide. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
213 mensajes |
|
| Publicado el 17,julio 2020 - 21:31 |
>J'ai exactement comme vous, une boite SQL reliée à une boite résultat
Windev semble dire qu'il est capable d'interpréter la requête.
Du coup, c'est maintenant la "logique SQL" qui est testée.
Le SUM() vs l'Alias.
Avouons que c'est logique de ne pas faire le calcul deux fois.
Un bug ma fois qui m'aura coûté la journée.
Depuis le temps, je dois avoir pour une année entière de ces bugs qui nous font perdre une journée.
Bon dev.
Serge
--
-----
Parfois, la logique est implacable... |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,julio 2020 - 10:02 |
Monsieur Serge a écrit :
J'ai exactement comme vous, une boite SQL reliée à une boite résultat
Windev semble dire qu'il est capable d'interpréter la requête. Du coup, c'est maintenant la "logique SQL" qui est testée. Le SUM() vs l'Alias. Avouons que c'est logique de ne pas faire le calcul deux fois. Un bug ma fois qui m'aura coûté la journée.
Depuis le temps, je dois avoir pour une année entière de ces bugs qui nous font perdre une journée. Bon dev. Serge
bonjour,
ce n'est pas un pb de faire le calcul 2 fois
la clause HAVING (qui n'est rien de plus qu'un filtre sur le résultat)
est toujours exécuter sur le résultat de la requête donc on ne fait pas
de SUM() dans un HAVING qui est le résultat de l'agrégation d'un GROUP
BY mais on met l'alias correspondant
--
Cordialement JeAn-PhI |
| |
| |
| | | |
|
| | | | |
| | |
|