Tri d'un table ayant des index

Bonjour à tous.

j'effectue des traitements sur une table, qui nécessitent un ordre de tri particulier des données existantes dans la table.
J'arrive à utiliser la clause ORDER BY mais je rencontre une énorme difficulté car je constate que l'ordonnancement est aléatoire.
Avec le même ordre de tri, quand je lance plusieurs fois mon traitement, je constate que l'ordre varie. Je me disais que c'était dû aux index (car certains champs utilisés dans le ORDER BY sont des index de la table), mais après avoir supprimé tous les index de la table, le résultat est toujours aléatoire comme si le ORDER BY n'agissait pas sur toutes les données de ma table.

Il me semble qu'une notion m'échappe dans l'application du ORDER BY mais je recherche en vain...Merci de bien vouloir m'éclairer
Ci-dessous une capture de ma table après application du ORDER BY. La ligne en surbrillance jaune est celle qui cause mon problème. j'ordonne ma table par DATE, IDENTIFIANT,NUMERO

Bonjour,

il doit manquer le champ CODRANG dans la clause ORDER BY non ?

Citation:

---

Envoyé par TheRussian

Bonjour,

il doit manquer le champ CODRANG dans la clause ORDER BY non ?

---

Merci pour ce retour. J'y ai pensé mais l’inconvénient avec CODRANG est qu'il y'a des lignes qui ont parfois en commun DATE,IDENTIFIANT,NUMERO. Dans ce cas, quand j'intègre CODRANG à mon ODER BY, j'obtiens un ordre très peu exploitable du fait des lignes qui ont en commun les trois autres champs du ORDER BY.
Pièce jointe 327802

Je voulais dire en ajoutant le champ CODRANG dans ORDER BY de la façon suivante :

Code:

---

1 2	SELECT ... ORDER BY DATE, IDENTIFIANT,NUMERO, CODRANG

---

De cette manière le tri devrait être correct non ?

Bonjour

Citation:

---

Envoyé par roadbecri

j'ordonne ma table par DATE, IDENTIFIANT,NUMERO

---

Il n'y a pas d'ordre dans une table;

Qu'essayez vous de faire, quelles requêtes exécutez vous ?

Citation:

---

Envoyé par TheRussian

Je voulais dire en ajoutant le champ CODRANG dans ORDER BY de la façon suivante :

Code:

---

1 2	SELECT ... ORDER BY DATE, IDENTIFIANT,NUMERO, CODRANG

---

De cette manière le tri devrait être correct non ?

---

Merci TheRussian pour ton retour. Comme je l'ai dit précedemment , toutefois que j'inclure CODRANG le tri n'est pas exploitable du fait que certaines lignes en en commun DATE, IDENTIFIANT, NUMERO.

Je ne comprend pas le problème avec cette requête :

Code:

---

1 2	SELECT ... ORDER BY DATE, IDENTIFIANT,NUMERO, CODRANG

---

Le ORDER BY va trier en premier par DATE puis pour les DATE identiques par IDENTIFIANT et ainsi de suite du coup l'affichage du résultat de la requête sera dans le bon ordre.

Pour le résultat sera bien celui attendu. As-tu essayé ? Quel résultat cela donne ?

Citation:

---

Envoyé par aieeeuuuuu

Bonjour



Il n'y a pas d'ordre dans une table;

Qu'essayez vous de faire, quelles requêtes exécutez vous ?

---

Ma table en question contient les données issues de certaines transactions comptables. Chaque transaction porte obligatoirement sur un IDENTIFIANT précis, une FACTURE (NUMÉRO) précise et une date précise. Chaque transaction enregistrée dans ma table génère 5 écritures (lignes avec pour repère comptable, le champ CODRANG) numérotées de 01 à 05 .
Mon objectif est de pouvoir trier ma table en ordonnant toutes les écritures (5 au maximum) d'une même transaction selon l'ordre de 01, 02, 03, 04, 05...ensuite passer à la transaction suivante...
Toutefois, il peut arriver que pour un même IDENTIFIANT, une même FACTURE, il y ait une ou plusieurs transactions le même jour: dans ce cas alors, toutes ces transactions auront en commun IDENTIFIANT,NUMERO, DATE. D'où incorrect de vouloir insérer CODRANG dans un quelconque ORDER BY.

Voici la requête que j'exécute :

Code:

---

1 2 3 4 5 6 7

select * from OPERCOMPTA where TYPE = '04' and NATURE = '600' and (DATEDIFF(dd,DATOPER,convert(datetime,'01/11/2016',103))<=0 and DATEDIFF(dd,DATOPER,convert(datetime,'30/11/2016',103))>=0) order by convert(char(8),DATOPER,112),IDENTIFIANT,NUMERO

---

Citation:

---

Envoyé par roadbecri

j'effectue des traitements sur une table, qui nécessitent un ordre de tri particulier des données existantes dans la table

---

C'est stupide de faire cela car par principe les SGBDR ne peuvent jamais garantir aucun ordre des lignes dans les traitements.

Si votre traitement est un calcul de cumul relatif ordonné comme je le présume, il faut le faire de manière ensembliste à l'aide de fonction de fenêtrage !
À me lire : http://sqlpro.developpez.com/article...clause-window/

Exemple :

Code:

---

SELECT *, SUM(MONTANT) OVER(PARTITION BY IDENTIFIANT ORDER BY DATE) AS CUMUL FROM...

---

A +

Juste pour pinailler :

Code:

---

DATEDIFF(dd,@DATOPER,convert(datetime,'01/11/2016',103)) <=0

---

c'est la version bien compliquée pour faire simplement :

Code:

---

convert(datetime,'01/11/2016',103) <= @DATOPER

---

Cela veut dire qu'il n'y a pas moyen d'identifier les transactions dans la table ?
Il manque un truc pour faire ce type de requête.
Une table n'étant pas un fichier séquentiel ...

Une BD c'est comme un sac. Vous y trouverez ce que vous y mettez et l'ordre ou le placement des choses peuvent changer du fait que le sac sert à transporter et que les objets roulent, s'entrechoquent se mêlent et s’emmêlent. Il n'est qu'à ouvrir un sac à main d'une de ces dames, pour constater qu'il n'y a pas d'ordre là dedans !!! :ptdr:

A +

Citation:

---

Envoyé par SQLpro

Si votre traitement est un calcul de cumul relatif ordonné comme je le présume, il faut le faire de manière ensembliste à l'aide de fonction de fenêtrage !
À me lire : http://sqlpro.developpez.com/article...clause-window/

Exemple :

Code:

---

SELECT *, SUM(MONTANT) OVER(PARTITION BY IDENTIFIANT ORDER BY DATE) AS CUMUL FROM...

---

A +

---

Merci pour votre retour SQLpro. Mais mon traitement ne s’intéresse pas au calcul. L'objectif de mon traitement est de faire des rapprochements avec une autre table, et pour cela il est nécessaire que ma table des opérations comptables sur la quelle je travaille actuellement soit juste triée par transaction: c'est à dire les 5 lignes d'une transaction (CODRANG 01,02,03,04,05), ensuite les cinq lignes d'une autre transaction, et ainsi de suite, sans pour autant faire des cumuls.

Toutefois je vous remercie pour le lien vers les fonctions de fenêtrage qui me semble exploitable, en espérant pouvoir y trouver mon "bonheur".
Merci

Citation:

---

Envoyé par TheRussian

Cela veut dire qu'il n'y a pas moyen d'identifier les transactions dans la table ?
Il manque un truc pour faire ce type de requête.
Une table n'étant pas un fichier séquentiel ...

---

Justement TheRussian un énorme handicap de la table des opérations comptables car il n'existe aucun élément permettant d'identifier les écritures d'une transaction spécifique. Ceci explique mon intention de me fier à l'ordonnancement, en espérant que 5 lignes successives (si mon ordre de tri était bon) désigneraient une même transaction mais que nenni !!!

Pour ce qui est de la structure de la table, j'ai déjà pris soin de corriger cet handicap en créant une clé unique par transaction, mais le problème demeure pour les données anciennes (2015 et 2016) à traiter.

Merci tout de même pour votre sollicitude!!!