problème d'order by [Résolu]

[michael08]

Bonjour,

j'ai une appli qui liste des remises. La requète qui me permet de retourner la liste contient un tri en descendant sur une date de règlement et un numéro de remise :

Code :

1
2
3
4
5
6
7
8
SELECT NUMREM, DATREG                     
         FROM TABLE               
         WHERE NUMPRS    = :w-numprs 
           AND ......     
           AND DATREG    <= :w-repdatreg  
           AND NUMREM    < :w-repnumrem     
         ORDER BY DATREG DESC, NUMREM DESC
FETCH FIRST 15 ROWS ONLY

Les prédicats datreg et numrem servent à se repositionner pour la pagination.
Les problèmes suivants se posent : on peut avoir deux remises i telles que datregi < datregj et numremi> numremj.

La requète telle qu'elle ne va donc pas m'afficher ces remises là.
Et si j'enlève le prédicat numrem, je ne me repositionne pas correctement.

Quelqu'un aurait il leu une expérience similaire et pourrai me donner une idée pour m'en sortir?

Merci d'avance!

[punkoff]

Bonjour,

Pourriez-vous joindre un jeu de test sommaire, explicitant votre problème actuel + le résulta attendu ?

Et préciser le sgbd par la même occasion.

[michael08]

Merci pour ta réponse.

Supposons que l'on ait deux pages 1 et 2 et que la date de reprise pour aller en page 2 est 30/05/2008 et le numéro de reprise est 1600. Le numéro et la date de reprise correspondent à la 15eme remise (la dernière retournée par la requète)
Lorsque je pagine, je réeffectue la requète. L'objectif étant de repositionner le curseur sur la 16eme remise.

Deux cas de figure peuvent se présenter :

cas 1: Si la remise suivante a pour date 30/05/2008 et comme numéro 1550, le prédicat numrem < 1600 me permet de bien me positionner.

cas 2: Si la remise suivante a pour date 30/04/2008 et comme numéro 1650, le prédicat numrem < 1600 ne me permettra pas de bien me positionner.

Le SGBD est DB2.

As tu besoin d'autres explications?

[punkoff]

Ok j'ai compris, un peu long ce matin.

Mais votre problème est indépendant de sql.

la couche applicative ne peut-elle pas gérer nativement ce genre de cas ?

[tatayo]

Bonjour,
Pour moi le critère n'est pas bon. Tu dois plutôt chercher les enregistrements qui ont (la même date et un numéro inférieur) OU (une date inférieur) à ta "pagination".

Tatayo.

[SQLpro]

En fait vous êtes dans un problème de ROW VALUE CONSTRUCTOR. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/select/#L8

Merci de respectez la charte de postage en donnant le DDL de vos tables et un jeu d'essais sous forme INSERT.

A +

[CinePhil]

Je doute aussi de la pertinence du processus.
Si j'ai bien compris, une requête te donne une liste de données trop longue pour être affichée en une seule page et tu ré-exécute la requête à chaque page. Si entre temps de nouvelles données sont arrivées, ta liste est perturbée.

Il faut que le logiciel récupère l'ensemble des données à afficher à un instant T et gère l'affichage par page sans ré-interroger la BDD.

[michael08]

Envoyé par punkoff

Ok j'ai compris, un peu long ce matin.

Mais votre problème est indépendant de sql.

la couche applicative ne peut-elle pas gérer nativement ce genre de cas ?

J'y ai pensé ce matin mais on peut avoir un nombre trés élevé de remises par critère de selection (jusque 10200 d'après un spufi(requète lancé en prod) ).
Je crains que la pagination soit alors gourmande en nombre d'ordre sql, puiqu' il faut que j'ouvre mon curseur et que je fetch jusqu'à me positionner correctement.

[michael08]

Envoyé par CinePhil

Je doute aussi de la pertinence du processus.
Si j'ai bien compris, une requête te donne une liste de données trop longue pour être affichée en une seule page et tu ré-exécute la requête à chaque page. Si entre temps de nouvelles données sont arrivées, ta liste est perturbée.

Il faut que le logiciel récupère l'ensemble des données à afficher à un instant T et gère l'affichage par page sans ré-interroger la BDD.

En effet mais le problème ne se pose pas puisque cette table n'est pas alimentée en TP mais qu'une fois tous les soirs.
De plus, la requète sans restreindre aux 15 premiers éléments pourrait etre trés longue et donc entrainer un U240 (Timout).

[michael08]

Envoyé par tatayo

Bonjour,
Pour moi le critère n'est pas bon. Tu dois plutôt chercher les enregistrements qui ont (la même date et un numéro inférieur) OU (une date inférieur) à ta "pagination".

Tatayo.

Non ça ne marchera pas ainsi car, et je reprends l'exemple plus haut, supposons que la dernière remise de la première page ait comme date 30/05/2008 et comme numéro 1600.

Et supposons qu'on ait un enregistrement de la première page qui ait comme date 30/06/2008 et comme numéro 1502.L'un des deux critères étant vérifié pour la remise, la requète positionnera alors mon curseur dessus!

[michael08]

Envoyé par SQLpro

En fait vous êtes dans un problème de ROW VALUE CONSTRUCTOR. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/select/#L8

Merci de respectez la charte de postage en donnant le DDL de vos tables et un jeu d'essais sous forme INSERT.

A +

Merci pour l'article! je vais le lire tranquillement cette après midi.

[michael08]

Envoyé par SQLpro

En fait vous êtes dans un problème de ROW VALUE CONSTRUCTOR. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlaz/select/#L8

Merci de respectez la charte de postage en donnant le DDL de vos tables et un jeu d'essais sous forme INSERT.

A +

Magnifique!!! C'est pile poil mon problème.

Merci à tous pour vos réponses!!!

[tatayo]

Envoyé par michael08

Non ça ne marchera pas ainsi car, et je reprends l'exemple plus haut, supposons que la dernière remise de la première page ait comme date 30/05/2008 et comme numéro 1600.

Et supposons qu'on ait un enregistrement de la première page qui ait comme date 30/06/2008 et comme numéro 1502.L'un des deux critères étant vérifié pour la remise, la requète positionnera alors mon curseur dessus!

Non, l'enregistrement en question ne valide pas le critère. Si je reprends ton exemple:
La dernière ligne de la première page a pour date le 30/05/2008 et numéro 1600
La ligne en exemple a pour date 30/06/2005 et numéro 1502.

Si tu récupère les lignes dont (la même date et un numéro inférieur) OU (une date inférieur), donc (la date = 30/05/2008 et numero < 1600) ou(date < 30/05/2008) la ligne qui a pour date le 30/06/2008 et numéro 1502 ne sort pas, car la date est supérieure à celle de la dernière ligne de la première page. Aucun des deux critères n'est vérifié.

Tatayo.

[michael08]

Envoyé par tatayo

Non, l'enregistrement en question ne valide pas le critère. Si je reprends ton exemple:
La dernière ligne de la première page a pour date le 30/05/2008 et numéro 1600
La ligne en exemple a pour date 30/06/2005 et numéro 1502.

Si tu récupère les lignes dont (la même date et un numéro inférieur) OU (une date inférieur), donc (la date = 30/05/2008 et numero < 1600) ou(date < 30/05/2008) la ligne qui a pour date le 30/06/2008 et numéro 1502 ne sort pas, car la date est supérieure à celle de la dernière ligne de la première page. Aucun des deux critères n'est vérifié.

Tatayo.

Oui. j'avais mal compris. Je pensais que tu voulais que je remplace simplement le AND par un OR.

C'est effectivement ce que j'ai fait. Et du coup je résoud deux problèmes d'un coup : le premier digit du numéro de remise correspond à l'année. Quand on est en 2010, le premier digit est 0. La première requète n'affichait pas les remises de l'année 2010 avant ceux de 2009 (premier digit à 9).

Avec ce petit changement, c'ets la date qui est pris en compte en priorité, donc j'aurais mes remises de 2010 en priorité!