Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Pages: 1





Bonjour,
Imaginons une requête simple qui me retourne des résultats comme suit :
- un type (entier variant de 1 à 4)
- un texte (variable, le contenu nous importe peu)
Jusqu'à présent j'affiche mes résultats les uns à la suite des autres sous la forme [type - texte]. Ca forme une grande "colonne" verticale de résultats.
Colonne 1
------------
type|texte
type|texte
type|texte
type|texte
type|texte
Le but du jeu c'est maintenant des les afficher sous forme de 4 grandes "colonnes" de résultats : 1 colonne par type :
Colonne 1 Colonne 2
------------ ------------
texte texte
texte texte
texte texte
texte texte
texte texte
Colonne 3 Colonne 4
------------ ------------
texte texte
texte texte
texte texte
texte texte
texte texte
Bien entendu cela peut se faire en incluant 4 sous-datawindow, chacune se chargeant de récupérer un seul type de rows (en leur passant en argumant le type qu'elles doivent rechercher dans leur procédure Oracle)... Mais cela signifie aussi qu'on va exécuter 4 requêtes Oracles.
Est-ce possible de faire une seule requête Oracle qui me retourne mes résultats, puis de les afficher sous forme de 4 colonnes dans ma datawindow, tout en ayant 2 colonnes en haut et 2 colonnes en bas et en utilisant le painter de Pb ?
Le cas échéant, je pensais à la solution suivante :
- Je place 4 sous-datawindows dans mon painter
- Je ne fais pas de retrieve sur ces dernières
- Je créée un datastore dans ma fenêtre, et je le remplis avec mes données
- Je parcoure mon datastore, et suivant le type de chaque row je l'ajoute à la bonne sous-datawindow.
Ca me parait être une solution intermédiaire plutôt pas mal : je fais 1 seule requête Oracle, par contre je perds du temps en traitements et aprcours des résultats. Je préfèrerais une solution "directe".
Qu'en pensez-vous ?
Dernière modification par Nyphel (28-07-2008 12:44:57)
Hors ligne











Pour la requête Oracle, tu peux faire des Group by
Hors ligne





Heu... Je ne suis pas pas du tout un spécialiste PL/SQL et Oracle, mais je ne vois pas trop comment utiliser le group by ici.
Mettons que j'ai 20 rows répartis sur mes 4 types : je veux toujours afficher mes 20 rows, mais avec 1 "colonne" par type.
Au lieu d'afficher une "colonne" avec 20 rows, je veux afficher 4 "colonnes" de 5 rows (par exemple).
Si j'utilise un group by sur mes types, je ne vais retourner que 4 rows, non ?
Hors ligne











Pas réveillé ce matin... J'ai confondu avec les group de la DW. mais ça ne te permettra pas d'avoir la présentation que tu souhaites...
Hors ligne














le nb de types (4) est fixé ?
Hors ligne





Théoriquement non, mais en pratique il ne devrait pas évoluer.
Hors ligne














si l'utilisateur n'a pas à éditer les données, tu peux partir sur :
Nyphel a écrit:
Bien entendu cela peut se faire en incluant 4 sous-datawindow, chacune se chargeant de récupérer un seul type de rows (en leur passant en argumant le type qu'elles doivent rechercher dans leur procédure Oracle)... Mais cela signifie aussi qu'on va exécuter 4 requêtes Oracles.
?
au niveau de la base : faire 4 retrieves pour chacun des types ne devrait pas être bcp plus pénalisant que faire un retrieve global (pour peu qu'il y ait un index sur le type et pas 10 millions de données)
au niveau de l'affichage : c'est kif-kif je pense (tu pourras faire le test)
Hors ligne





D'accord, j'espérais secrètement qu'il y ait une autre façon de faire ;)
Par acquis de conscience, je pense que je vais tenter de faire une seule requête via un datastore, puis afficher mes résultats en parcourant le datastore et en les copiant dans les sous-datawindows. C'est faut peut-être un gros schmilblik pour pas grand chose, mais bon...
Merci pour vos conseils avisés !
Hors ligne














Nyphel a écrit:
Par acquis de conscience, je pense que je vais tenter de faire une seule requête via un datastore, puis afficher mes résultats en parcourant le datastore et en les copiant dans les sous-datawindows. C'est faut peut-être un gros schmilblik pour pas grand chose, mais bon...
effectivement ça ne me semble pas très utile...
et niveau performance c'est pas forcément mieux
more code = more bugs
less code = less bugs
Hors ligne
Pages: 1