Ordre d'affichage du résultat d'une requête SELECT

[randriano]

Bonjour,

Je me demande si lorsqu'on fait un SELECT simple (pas de jointure) sur une table, l'ordre d'affichage des records trouvés ne doit-il pas être toujours le même (table inchangée) ? C'est du moins ma constatation, ça ne change pas (avec SQL plus, avec des outils tiers comme SQL Manager, un programme que j'écris utilisant ADO, etc.). Même avec une table sous SQL Server avec les même données, ça parait être même ordre (mais je dois encore revérifier)

J'ai posé cette question car récemment (aujourd'hui), il m'est arrivé que dans un 2è prog que j'ai écrit (en C++ avec ADO), l'ordre n'est plus le même et ça a causé une exception de ->MoveNext() !!! Est-ce que par hasard quelqu'un d'ici aurait déja rencontré cette situation ?

[Vincent Rogier]

en théorie, un select simple sans jointure et sans clause order by trie le résultat par rowid (donc ordre de création)

[philcero]

Apparemment ADO peut rencontrer des problèmes avec l'ordre de traitement des rowid.
Va voir cet article de chez Microsoft qui donne une méthode : INFO: Oracle OLE DB Provider and ROWID Use

[randriano]

Apparemment ADO peut rencontrer des problèmes avec l'ordre de traitement des rowid.

J'ai lu l'article mais moi, j'utilise le provider d'Oracle !!

Si le résultat est trié selon ROWID, l'ordre doit donc toujours être le même même avec une table oracle exportée vers sql server (j'ai vérifié ça affiche même ordre sous ems sql manager)!! Mais dans mon application, c'est en désordre encore; bon, je vais vérifier pourquoi

[McM]

Ce n'est pas une certitude 100%

Si tu veux que le tri soit toujours pareil, il faut le faire explicitement.

[randriano]

Il me semble qu'un select simple est toujours dans l'ordre du ROWID (implicitement bien sur) !!
Mon cas est assez délicat car même si j'ajoute "ORDER BY ROWID", l'ordre ne se fait toujours pas !!!!!!!!!!!!! (sous ADO bien sur)


Scénario:
SELECT nom, matricule FROM matable;

Le count (nombre de records) résultant est de 14. En bouclant pour lire un à un les enregistrements, ça crash à la 7è boucle (toujours ordre dans le désordre) avec l'erreur: "BOF ou EOF est égal à True ou l'enregistrement actuel a été supprimé. L'opération demandée nécessite un enregistrement actuel."

[laurentschneider]

non, ce n'est pas le cas.

On ne peut pas déterminer l'ordre. On peut dire "c'est souvent le cas", mais impossible de savoir.

Cela dépend par exemple du plan d'execution, qui peut changer en fonction des statistiques. Par exemple si un index est utilisé, ou un accès parallèle aux partitions, ou autre cas, on ne peut pas savoir dans quel ordre les lignes seront retournées.

Il n'y a aucune raison de croire que l'on recevra toujours les lignes dans le même ordre si l'on employe pas order by :!

Quant à MoveNext, aucune idée

[randriano]

On ne peut pas déterminer l'ordre. On peut dire "c'est souvent le cas", mais impossible de savoir.

D'accord laurent ! En effet, ce n'est pas fixe mais l'ordre ne doit pas être si différent que ça si aucune modif n'est faite dans la table.

Mais ce qui m'arrive maintenant c'est que l'ordre obtenu dans mon nouveau programme est si désordonné que le programme crash à la lecture de la 7è parmi 14. Ce 7è est le dernier résultat normalement sur les autres (sql plus, mon ancien prog, etc.). Bon, je vais voir quelle est l'erreur ?

[laurentschneider]

si la table a subit des deletes et des inserts, alors les lignes ne sont plus dans l'ordre de ROWID, il se peut aussi que la table ait des extents non contigus, voire des extents dans différent fichiers.

Un explain plan et un select rowid pourra éventuellement te donner un indice sur la cause de tes soucis!

[philcero]

Je vais peut-être répondre à côté de la plaque mais quel est l'intérêt d'avoir les enregistrements d'une table dans un ordre jugé comme immuable si celui-ci ne l'est pas explicitement demandé à la base ?

Par extension, le fait que la fonction MoveNext() pré-citée plante doit peut-être être lié à autre chose. Pour ma part un curseur, que celui-ci soit en PL/SQL, en Java, en C ou je ne sais quoi d'autre reste un curseur et est censé apporter une certaine contractualité avec le contenu que retourne la base.

Autrement dit le problème ne viendrait-il pas plus tôt d'une mauvaise implémentation de ton API et non du driver utilisé ?

[orafrance]

Par définition une table est un sac de billes, il n'y a donc aucun ordre garanti et en aucune manière le ROWID pourrait le garantir, en effet, un UPDATE ou MOVE suffit à le changer

A retenir : la norme impose de me pas ordonner les lignes d'une table

[laurentschneider]

Envoyé par orafrance

un UPDATE ou MOVE suffit à le changer, même une migration de ligne

Pourrais-tu détailler stpl?

C'est quoi une migration de ligne?

[orafrance]

C'est un chainage qui consiste à déplacer la ligne complète et laisser juste le pointeur dans le bloc d'origine. Si tu fais un update d'une ligne mais que le bloc n'a pas suffisamment d'espace libre pour faire cet update, alors la ligne complète est déplacer dans un nouveau bloc.

A ne pas confondre avec le chainage "simple" qui lui est difficilement coutournable puisqu'il consiste à répartir une ligne sur différent bloc si elle est plus grosse que le bloc (ou plutot le PCTUSED du bloc).

Edit : Pour approfondir le sujet : http://www.developpez.net/forums/d18358/bases-donnees/oracle/question-techniques-extents/

Particulièrement, la doc : http://download-west.oracle.com/docs...lock.htm#15915

PS : D'ailleurs, la doc corrige une bêtise que j'ai dite : la migration de ligne ne modifie pas le ROWID... au temps pour moi (J'ai donc supprimé cette précision fausse de mon post )

[mnitu]

Envoyé par randriano

...
Le count (nombre de records) résultant est de 14. En bouclant pour lire un à un les enregistrements, ça crash à la 7è boucle (toujours ordre dans le désordre) avec l'erreur: "BOF ou EOF est égal à True ou l'enregistrement actuel a été supprimé. L'opération demandée nécessite un enregistrement actuel."

Si je comprends bien il y a plutôt un problème dans l’algorithme que tu utilise : en général tu ne peut pas te baser sur le comptage des enregistrements fait avec un select count(*) pour ouvrir et lire les données dans un curseur. Plus explicitement, l’algorithme suivant est mauvais :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
declare
  cursor crs IS SELECT * FROM emp;
  l_cpt Number;
  l_rEmp emp%rowtype;
begin
  SELECT count(*) INTO l_cpt  FROM emp;
  Open crs;
  FOR i IN 1..l_cpt Loop
    Fetch crs INTO l_remp;
  End Loop;
  Close crs;
End;

[randriano]

Et oui mnitu, c'est comme ça que je fais mais sous ADO C++. Normalement, ça marche mais pour mon cas à la 7è record des 14, ça plante avec l'erreur que j'avais mis en rouge.

Envoyé par philcero

quel est l'intérêt d'avoir les enregistrements d'une table dans un ordre jugé comme immuable si celui-ci ne l'est pas explicitement demandé à la base ?

Juste par curiosité !!

[mnitu]

Peu importe que c'est ADO avec C++, PL/SQL, VB ou Java! L'algorithme est mauvais (oubliez complètement le order by dans cette hystoire)!

Normalement ça marche...

Le monde est plein des bugs qui marchent "normalement"!

[philcero]

Ca fait un bout de temps que j'ai pas fait du C++ mais si c'est faisable poste ton code, car pour moi le problème vient de là et pas d'ailleurs...

[orafrance]

le problème vient de la requête et non du code C++

[randriano]

Désolé de me manifester aussi tardivement.

Envoyé par philcero

car pour moi le problème vient de là et pas d'ailleurs...

En effet, l'erreur ne vient pas du tout de la requête qui est très simple et correct mais du programme C++.
Aussi que ça soit même moi je n'arrive pas à comprendre, il s'avère que ça ne marche pas car j'ai changé les tabulations du code par rapport à l'ancien, j'ai enlevé les commentaires inutiles.

Envoyé par philcero

si c'est faisable poste ton code

Désolé je ne peux pas pour l'instant mais il s'agit du CPP d'une classe pour questionner une bd. Entre l'ancienne et la nouvelle, seulement différence de tabulations et suppression de commentaires. Bon

[randriano]

Et ben, j'ai maintenant clairement identifié la source de l'erreur, c'est purement C++ et ADO!!
En fait, la lecture du recordset issu d'une requête Select crashe alors lorsque le tupe de curseur Internal::CursorLocationEnum des fonctions Open() est égal à Internal::adUseServer. Puis si je change en adUseClient, ça ne change pas car il fallait regénérer le projet C++ (nettoyer puis compiler) pour que le changement d'ADO soit pris en compte.
Et ben, il est bizarre l'ADO, le fait de toujours regénérer pour voir la modification du curseur
(car si je change ensuite en adUseServer, ça marche mais il faut regénérer pour voir que ça plante)