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).
(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:
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...
mais ne pas arriver à tester/exécuter directement 3 malheureuses requêtes SELECT imbriquées, là franchement... zéro pointé !
Et même...
[/HUMEUR !]
Pour l'heure, tant pis.
Mais je trouve que c'est vraiment dommage et très décevant.
_
Partager