J'ai un gros problème, je suis débutant sous oracle, et j'ai besoin de faire une liste paginée avec un tri sur chaque colonne.

Ca fait des heures que je cherche comment effectuer cette pagination en utilisant des clauses order by group by dans mes requetes, mais après pas mal de recherches, je ne trouve rien qui marche.

Dès que je tri ma liste, les elements de la nième page ne sont plus les mêmes, et je ne peux pas faire de order by rowid a cause de mes clauses group by...

Pour info voila la tête de ma requete :

J'ai essayé d'appliquer cette méthode (ou ci-dessous) mais sans succès, la pagination marche (50 par 50 ici), mais je ne peux pas me servir des critères de tri (order by n'importe quel champ du 1er select bien sur) car oracle refuse le order by rowid sur un group by

Chaque fleche sur la photo ci dessous tri la liste par ordre croissant ou decroissant de nom, vs ou autre...
Si je pagine la liste, et que je n'utilise pas les critères de tri, je n'ai pas besoin de faire un order by rowid apparement d'apres le lien ou j'ai trouvé la solution de pagination
Par contre si je tri sans mettre ce 'order by rowid', par exemple je me positionne sur la page 1 (le nom des lignes  va de 'a' à 'h', si je tri par nom desc je n'aurait pas les ligne inversées (de 'h' à 'a' ) mais de 'z' à ' r', le tri ne se fera pas que sur les éléments de la page 1 mais sur toute la liste comme s'il elle n'était pas paginée et donc les élements de ma page 1 après le tri n'ont plus rien avoir avec ce qu'il était avant.

Si vous pouviez me donner un coup de main ça me sauverai car je suis dans une impasse , je pense qu'il y a un moyen d'implémenter ce qui est écris dans le lien, mais je n'y parviens pas.

EDIT : Désolé d'avoir trafiqué le screen, données sensibles oblige

OK, je viens de piger ton problème.
 
Il faut dire que c'est assez étrange ton truc : normalement, le tri fonctionne comme tu ne veux pas. En tout cas, j'ai toujours vu faire comme ça
 
Effectivement, la pagination se fait une fois les données triées, et non l'inverse.
 
Toi, ce que tu semble vouloir faire, c'est trier une seconde fois le résultat, pour afficher les données paginées selon un autre tri que le tri principal...
En soit, c'est un peu bordelique, dans la mesure ou l'utilisateur doit spécifier deux tris distincts, à moins que celui "global" ne soit "en dur".
 
Bon, je vais voir ce que je peux faire. A mon avis, c'est très simplement résolvable avec deux order by : un au niveau de ta sous-requête, et un second ensuite dans la requête finale... Mais cela demande un niveau supplémentaire d'imbrication. J'espère qu'Oracle va comprendre ton idée farfelue

Dans mon test, je vais faire ceci :
 
Requête principale : recherche des commandes d'une base, avec comme informations : numéro de commande, nombre de lignes de la commande, et montant total de la commande
 
Premier tri permettant de trier mes pages par "numéro de commande".
Second tri permettant de trier l'intérieur de ma pase par "nombre de produits"

Merci beaucoup MagicBuzz , je crois que je suis pas sorti du taf avant  minuit

Ben en fait, c'est tout peanuts, même pas besoin de rajouter un niveau :

SELECT numeve, nblig, montant
FROM
(
    SELECT rownum ligne, numeve, nblig, montant
    FROM
    (
        SELECT eve.numeve, count(*) nblig, sum(evp.qtecde * evp.prxvdu) montant
        FROM eve
        INNER JOIN evp ON evp.codsoc = eve.codsoc AND evp.achvte = eve.achvte AND evp.numeve = eve.numeve
        WHERE eve.codsoc = 2
        AND eve.achvte = 'V'
        AND eve.typeve = 'CDV'
        AND eve.dateve LIKE '200705%'
        GROUP BY eve.numeve
        ORDER BY numeve
    )
    WHERE rownum < 150
)
WHERE ligne > 140
ORDER BY nblig

 
Explication :

SELECT eve.numeve, count(*) nblig, sum(evp.qtecde * evp.prxvdu) montant
FROM eve
INNER JOIN evp ON evp.codsoc = eve.codsoc AND evp.achvte = eve.achvte AND evp.numeve = eve.numeve
WHERE eve.codsoc = 2
AND eve.achvte = 'V'
AND eve.typeve = 'CDV'
AND eve.dateve LIKE '200705%'
GROUP BY eve.numeve
ORDER BY numeve

 
Recherche des informations sur les commandes du mois de mai triées par numéro de commandes.
 

SELECT rownum ligne, numeve, nblig, montant
FROM
(
    SELECT eve.numeve, count(*) nblig, sum(evp.qtecde * evp.prxvdu) montant
    FROM eve
    INNER JOIN evp ON evp.codsoc = eve.codsoc AND evp.achvte = eve.achvte AND evp.numeve = eve.numeve
    WHERE eve.codsoc = 2
    AND eve.achvte = 'V'
    AND eve.typeve = 'CDV'
    AND eve.dateve LIKE '200705%'
    GROUP BY eve.numeve
    ORDER BY numeve
)
WHERE rownum < 150

 
On ne garde que les 150 premières commandes.
 

SELECT numeve, nblig, montant
FROM
(
    SELECT rownum ligne, numeve, nblig, montant
    FROM
    (
        SELECT eve.numeve, count(*) nblig, sum(evp.qtecde * evp.prxvdu) montant
        FROM eve
        INNER JOIN evp ON evp.codsoc = eve.codsoc AND evp.achvte = eve.achvte AND evp.numeve = eve.numeve
        WHERE eve.codsoc = 2
        AND eve.achvte = 'V'
        AND eve.typeve = 'CDV'
        AND eve.dateve LIKE '200705%'
        GROUP BY eve.numeve
        ORDER BY numeve
    )
    WHERE rownum < 150
)
WHERE ligne > 140
ORDER BY nblig

 
On ne prends parmis que les 150 sélectionnées qu'à partir de 140, en triant cette fois par nblignes.
Et ça marche

D'autres questions ?

T'es un dieu
 
C'était super con, merci encore et encore pour ta patience et ta sympathie
 
EDIT: J'ai bien testé et ça marche nickel  

Ahhhhhhhhh comment je fais pour avoir le nombre de lignes qu'aurait retourné la requete sans la pagination?

Bon je suis désolé MagicBuzz, mais je me rends compte que ce que je voulais faire est compltement débile , ça doit être la fatigue, je me retrouve à ne plus pouvoir trier ma liste entierement mais uniquement page -> sans intéret.

Etant donné que de limiter le nombre d'enregistrement revient au même que de tout prendre au niveau perf, autant que je fasse un array_slice() sur mon tableau avant l'affichage (enfin je crois, a moins que tu connaisses une bonne syntaxe pour gagner en perf, mais pour l'instant je vois aucune différence entre paginer 10 par 10 ou afficher 400 d'un coup) .

Le souci, c'est que si demain tu passes à une architecture n-Tiers (SGBD et application sur deux serveurs distincts) tu vas avoir un problème de bande passante entre les deux.
 
Effectivement, à un pouillème prêt, en local, récupérer 10 lignes dans une requête, ou 100 000 lignes, ça change pas grand chose (faut quand même penser à l'occupation mémoire qui se prends une sérieuse claque mais bon).
 
Par contre, quand les 10 ou 100 000 lignes passent à travers une connexion réseau, même en 1 Gbps, y'a une réelle différence.
 
Bon, après, passer de 10 à 400, c'est moins parlant, d'autant que si les lignes sont pas trop grosses, si ça se trouve ça va même pas générer de trame supplémentaire
 
Sinon, après c'est en fonction du langage d'interrogation.
Avec ADODB, on peut faire un select sans filtre (donc 100 000 lignes) qui restent sur le serveur, récupérer le nombre de lignes, puis récupérer sur le client uniquement les lignes "140 à 150". Je te laisse chercher dans la doc de ton langage (PHP ?) pour voir si tu peux reproduire un tel comportement.
 
En gros, faut que tu regardes s'il existe des "recordset serveurs".

Mouais, je vois , ma base est assez légère (30Mo) et au pire je fais un calcul sur pratiquement (sum) tout mais le résultat de ma requete ne me retourne au pire que 500 lignes, et seulement une dixaine de champs.
 
D'après ce que tu viens de me dire, je doute qu'il soit utile de me prendre la tête.

Merci beaucoup de ton explication en tout cas