[WD12] Exécuter une requête basée sur une autre requête

Version imprimable

25/11/2009, 16h30
=JBO=

[WD12] Exécuter une requête basée sur une autre requête

Bonjour,

Vous arrive-t-il de créer des requêtes dans l'éditeur dans le but de les utiliser dans d'autres requêtes ?

Dans Access, cette pratique est évidente et simplissime.

Mais qu'en est-il avec HyperFile Classic ou Client/Serveur ?

Bien sûr, j'ai fait plusieurs essais avant de poser cette question.
Il se trouve que lorsque j'exécute une requête qui en utilise une autre en appuyant sur le bouton GO, alors j'ai une erreur: le 'fichier <nom de ma requête> est inconnu' !

Merci pour vos pistes. :D

[EDIT]
J'ai mis au propre quelques informations concernant le fonctionnement d'une application WinDev avec le moteur HyperFile dans la discussion suivante:
http://www.developpez.net/forums/d91...eur-hyperfile/
[/EDIT]
_
26/11/2009, 20h23
=JBO=

Re-bonjour,

Citation:

Envoyé par =JBO=

Vous arrive-t-il de créer des requêtes dans l'éditeur dans le but de les utiliser dans d'autres requêtes ?

Apparemment personne n'utilise ce type de fonctionnalité avec HF... :?

Et pourtant, imaginons l'union de différents "fichiers tables", sur laquelle on applique un regroupement et qu'on utilise dans une sous-requète de sélection...
(bon, j'exagère un peu... :lol:).

Cela se fait facilement avec 3 requêtes:
- la requête A réalise l'UNION sur les "fichiers tables",
- la requête B effectue le GROUP BY sur A,
- la requête C utilise B dans une clause:
____ WHERE rubrique IN (SELECT B.rubrique FROM B)

Comment faites-vous avec HyperFile ???
_
27/11/2009, 14h15
klbsjpolp

J'ai déjà utilisé une requête dans une requête, mais je ne me souviens plus pourquoi, j'ai arrêté. Peut-être à cause d'un problème du genre...
18/12/2009, 12h18
=JBO=
Bonjour,

Ici je ne parle que de requêtes qui sont enregistrées dans le projet.

Pour répondre à la question, il faut distinguer (1) le test d'une requête, et (2) son utilisation dans une application.

(1) Test de requêtes imbriquées

En règle générale, on peut tester directement une requête B qui fait référence à une autre requête A du projet (toutes deux créées avec l'éditeur et analysées par WinDev).
Je dis en "règle générale", parce que si la requête A est une requête "sans correction" (donc pas analysée par WinDev) alors il faut d'abord tester la requête A et laisser ouverte la fenêtre d'aperçu du résultat, puis ensuite il est possible de tester la requête B.

D'autre part, je n'ai pas réussi à tester l'imbrication à 3 niveaux:

Requête C, utilise requête B qui utilise requête A.
Impossible d'afficher l'aperçu des données de la requête C (même avec les aperçus de A et B ouverts). :aie:

(2) Utilisation des requêtes imbriquées dans une application

Alors là, il n'y a pas le choix.
Il faut exécuter une à une toutes les requêtes en commençant par la plus imbriquée et en suivant les dépendances.

Pour récupérer les données de la requête B qui utilise la requête A, il faut exécuter le code suivant:
Code:

1 2 HExécuteRequête(A) HExécuteRequête(B)
Et j'ai vérifié que ça fonctionne correctement à 3 niveaux d'imbrication dans l'application (même s'il était impossible de tester !).

Voilà ce que j'ai constaté avec WinDev 12.
D'autres peuvent-ils confirmer ou infirmer cela, notamment pour WinDev 14 ?

[HUMEUR !]
Est-ce que la version 15 sera aussi pitoyable ?

Parce que faire une démo sur 15 milliards de lignes c'est bien joli... :fem:
mais ne pas arriver à tester/exécuter directement 3 malheureuses requêtes SELECT imbriquées, là franchement... zéro pointé ! :evilred:
Et même... :sm:
[/HUMEUR !]

Pour l'heure, tant pis. :(
Mais je trouve que c'est vraiment dommage et très décevant.
_
21/12/2009, 18h02
Bowen
C'est pas quelque chose que j'ai l'habitude de faire, parce que niveau perf je crois que ça plombe, mais chez moi, quand j'ouvre l'éditeur de requête assisté, il me propose bien mes requêtes.
J'ai peut-être une différence, c'est que mes requêtes sont d'abord créées dans l'analyse, puis partagées avec mon code.

Ça expliquerait pourquoi quand l'aperçu est lancé ça fonctionne. (je pense que le fait de lancer l'aperçu déclare la requête au moteur HF)

Par contre, niveau performances, j'ai bien peut que ce genre de chose soit à éviter autant que possible.

J'ai déjà eu à faire ce genre de chose (en prévenant le client qu'il attendra 5 minutes avant d'avoir sa réponse), et j'ai utilisé une requête définie dans le code. Un truc du genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 SELECT SUB1.Champ1 FROM ( SELECT A1 AS Champ1 FROM Table1 UNION SELECT A2 AS Champ1 FROM Table2 ) AS Sub1 GROUP BY Sub1.Champ1 HAVING...
07/01/2010, 20h36
=JBO=

Bonjour,

Merci Bowen pour ta réponse.

Une requête peut (1) être définie localement au projet, ou (2) être définie dans l'analyse pour être partagée avec le projet.

Citation:

Envoyé par Bowen

[...] chez moi, quand j'ouvre l'éditeur de requête assisté, il me propose bien mes requêtes.
J'ai peut-être une différence, c'est que mes requêtes sont d'abord créées dans l'analyse, puis partagées avec mon code.

Ça expliquerait pourquoi quand l'aperçu est lancé ça fonctionne. (je pense que le fait de lancer l'aperçu déclare la requête au moteur HF)

L'éditeur de requête "voit" aussi très bien les requête définies localement au projet.

Existerait-t-il des différences à l'exécution des requêtes selon qu'elles sont locales au projet, ou définies dans l'analyse ? :question:

En HyperFile Classic, y-a-t-il un intérêt à définir les requêtes dans l'analyse ?
_
25/01/2010, 16h27
=JBO=
Bonjour,
Citation:
Envoyé par =JBO=

(2) Utilisation des requêtes imbriquées dans une application

Alors là, il n'y a pas le choix.
Il faut exécuter une à une toutes les requêtes en commençant par la plus imbriquée et en suivant les dépendances.

Pour récupérer les données de la requête B qui utilise la requête A, il faut exécuter le code suivant:

Code:

1 2 HExécuteRequête(A) HExécuteRequête(B)

Et j'ai vérifié que ça fonctionne correctement à 3 niveaux d'imbrication dans l'application (même s'il était impossible de tester !).

Voilà ce que j'ai constaté avec WinDev 12.
D'autres peuvent-ils confirmer ou infirmer cela, notamment pour WinDev 14 ?
Depuis ce message, je suis enfin tombé sur la page de l'aide en ligne qui traite du sujet: cela s'appelle une Requête de requête.
Ce mode de fonctionnement concerne WD9 et suivants.

Citation:

Envoyé par =JBO=

Existerait-t-il des différences à l'exécution des requêtes selon qu'elles sont locales au projet, ou définies dans l'analyse ? :question:

En HyperFile Classic, y-a-t-il un intérêt à définir les requêtes dans l'analyse ?

Si j'ai bien compris, définir une requête dans l'analyse n'a de réelle utilité qu'avec HF C/S. A partir d'une analyse, on peut déployer sur le serveur des collections de procédures (qui seront des procédures stockées) ainsi que des requêtes (qui seront des requêtes stockées)

Les procédures stockées peuvent exécuter des requêtes stockées.
Et inversement, les requêtes stockées peuvent exécuter des procédures stockées.

En revanche, en HF Classic il n'y a aucun intérêt à définir une requête dans l'analyse (sauf en prévision d'une migration en HF C/S ?).
_
21/04/2010, 19h27
GCASPIC10

Imbrications de requêtes

Intéressant tout celà !

Je vous rejoints sur le plan absence de simplicité comparativement à ACCESS qui lui, propose un assistant simple pour la création d'une "requête de non correspondance" entre 2 tables.

Je pense finalement que cette imbrication de requêtes est malheureusement incontournable lorsque que l'on veut procéder à un échange de données entre 2 tables, suite à une sélection dans une combo actualisée.

Contrairement à vos propos, il me semble que ce principe de vase communiquant peut être utiliser assez fréquemment (c'est à dire, je sélectionne une ligne dans une combo par exemple, celle-ci va se loger dans la table réceptrice et de fait, disparaître de la liste combo). Idem pour l'opération inverse bien sur !

Le tout ne fonctionnant finalement que s'il y a initialisation dans l'ordre des requêtes imbriquées par la fonction "HExécuteRequête"

Y a t'il plus simple ? A suivre ...