Discussion :

[Access_ible]

Bonjour.

J'ai un petit souci, que j'ai déjà eu, … heu…, en fait trois soucis du coup :

Deuxième soucis : Je ne sais plus comment je l'ai résolu la dernière fois,

Troisième soucis : je suis convaincu de ne pas être le seul avec ce problème mais je n'arrive pas à lancer une recherche créant une remontée de réponses pertinentes sur le forum (j'ai beaucoup de réponses sur des tris sollicités qui ne retournent pas les résultats attendus).

Premier souci :

Pour un projet que j'imaginais plutôt léger, avec une portée limité, j'ai une table que j'ai créée il y a quelques années, avec un champ N° auto qui s'incrémente à chaque nouvelle ligne.

Au fil des années, j'ai ajouté des champs et cette table est devenue un de ces tableaux Excel de 3 m de large.

J'ai, bien entendu, fait des formulaires...

J'ai donc décidé de retailler cette table en plusieurs plus petites et de reporter une copie du N° auto dans chacune, dans un champ numérique que j'ai appelé "AncienLien".

Reste le quignon de la table d'origine qui comporte encore quelques champs utiles dont celui du N° auto.

Une seconde table, issue de la table d'origine, doit elle aussi comporter un N° auto, différent de celui de la table d'origine.

J'ai aussi créé un champ numérique "AncienLien" dans lequel j'ai recopié le N° auto.

En écrivant cette description, j'en viens à me demander si je ne me suis pas contenté de modifier le type de données en le passant de "NuméroAuto" à "Numérique".

J'ai tenté d'ajouter le champ "NouveauLien" avec "NuméroAuto" comme type de données.

Mais, le souci, c'est que le tri croissant effectué sur l'ancien numéro (champ numérique "AncienLien"), n'est pas conservé lors de l'ajout du nouveau champ "NouveauLien" qui porte le "NuméroAuto".

Toutes mes tentatives de trier la table sur "AncienLien", ensuite d'ajouter le champ "NouveauLien" avec "NuméroAuto", aboutissent à un tri dans lequel "AncienLien" et "NouveauLien" ne sont pas dans le même ordre.

Même en faisant une copie de la table pour ne garder que le champ "AncienLien", celui-ci reste dans son ordre mystérieux (et non souhaité).

Dans les propriétés de la table, inscrire en dur "AncienLien" sur la ligne Tri par et Oui sur la ligne Trier sur chargement n'y change rien (en tous cas dès lors que je rajoute un N° auto).

La table semble (et je me doute que l'on n'est pas ici en présence d'une possession maléfique, mais qu'il doit y avoir une raison) se trier seule, et toujours de la même manière.

Les enregistrements sont dans le même ordre à chaque fois, mais je ne trouve aucun champ qui semble trié.

Et cet ordre ne correspond pas non plus à l'ordre croissant qui utilisait le N° auto dans la table d'origine.

En plus, avec la ligne Tri par laissée vide, et même Trier sur chargement sur Non, ce tri mystérieux perdure.

Cela m'arrangerait bien que le nouveau N° auto soit dans le même ordre que l'ancien.

J'ai bien tenté une requête création de table, avec tri croissant sur le champ "AncienLien".

La table créée est triée par défaut sur "AncienLien" et l'ajout du N° auto se fait dans l'ordre.

Mais certaines propriétés des champs ont leur valeur par défaut (Valeur par défaut par exemple) et pas celles de la table source et aucune description de champ ne suit, bien sûr.

En gros, il semble y avoir un tri par défaut, toujours le même, mais je ne sais pas lequel il ne semble correspondre à aucun champ.

Est-il possible que les enregistrements soient "marqués" et qu'Access effectue un tri sur ce marquage ?

Comment solutionner, ou, au moins, comprendre ce mystère ?

D'avance merci.

[loufab]

Bonjour,

J'ai dû rater le moment où tu expliques pourquoi le fait d'avoir les id dans l'ordre te dérange. Une base de données n'a rien à voir avec un tableau Excel (je n'emploie volontairement pas le mot table pour Excel), là où pour l'un l'ordre des lignes est important et maitrisable, pour l'autre les enregistrements n'ont pas besoin d'être triés dans la table car les requêtes sont là pour faire le job.

Si tu tentes d'utiliser une colonne numéroauto dans chaque table pour établir la relation (si c'est bien ce que tu tentes de faire) je peux te certifier que ce n'est pas la bonne approche.

La bonne approche c'est une clef primaire et des clefs externes en numérique long.

Cordialement,

[Access_ible]

Bonjour.

Je suis un de vos grands fans et je ne compte plus le nombre de fois où je me suis servi d'une de vos réponses trouvées sur ce forum pour me sortir de l'impasse.

Merci.

Et merci pour cette réponse.

[...]le moment où tu expliques pourquoi le fait d'avoir les id dans l'ordre te dérange[...]

Ne faisait volontairement pas partie des éléments que j'ai précisé dans mon premier message...

Il faudrait que les id soient dans l'ordre dans la table, pour que quand on trie les enregistrements par id, ils soient dans leur ordre de saisie.

C'est ici l’équivalent de lignes ou de pages numérotées dans un journal de bord.

[...]Si tu tentes d'utiliser une colonne numéroauto dans chaque table pour établir la relation (si c'est bien ce que tu tentes de faire) je peux te certifier que ce n'est pas la bonne approche.[...]

Ce n'est pas ce que je cherche à faire.

Je sais établir des relations entre les tables.

J'ai deux tables et chacune doit avoir une numérotation auto qui ne vont pas servir ensembles.

En fait, ici, il me semble que la question n'est pas de savoir pourquoi je veux faire cela.

Mais, plutôt, de comprendre pourquoi ce qui se produit se produit et si il est possible de contourner cette situation.

J'aimerais savoir comment il se fait que les enregistrements soient toujours dans le même ordre (non sollicité et non logique de prime abord) dans une table quand on l'ouvre (si en plus ça n'a pas d’intérêt, comme vous l'expliquez clairement plus haut et je me rallie à votre opinion) et s'il est possible d'influencer de tri "par défaut en toile de fond".

Encore merci.

[f-leb]

Bonsoir,

Je ne suis pas sûr d'avoir bien compris, mais dans les objets Access (tables, requêtes, formulaires, états), il y a la possibilité d'enregistrer les ordres de tri. On peut sauvegarder le dernier ordre de tri appliqué à l'objet pour le récupérer à la prochaine ouverture ou sauvegarder un ordre de tri par défaut. Voir Enregistrer un ordre de tri avec une table, une requête, un formulaire ou un état

[Access_ible]

Bonsoir.

Merci pour ce suivi.

Je vais essayer d'être plus clair.

J'ai une table avec un champ qui contient un N°.

Ce N° était autrefois un N° auto. Maintenant c'est juste un champ Numérique.

Je souhaite (peu importe quelle est la raison derrière ce souhait) insérer un nouveau champ N° auto dont la numérotation soit dans le même ordre que l'ancien N°.

L'ancien N° n'est pas continu, la numérotation saute des chiffre parce que j'ai supprimé certains enregistrements.

Mais, si je tri par ce N°, le 15 est après le 10 qui est après le 5 (5, 10, 15,...).

Si j'ouvre la table sans rien toucher, ou si je recopie la table et que je n'en garde que le champ Ancien N° et que je l'ouvre sans rien toucher, elle se trie seule selon un critère qui m’échappe, mais toujours dans le même ordre (et pas un ordre qui m'arrange).

Peu importe comment je tris la table, au moment d'ajouter le champ N° auto, et surtout avant de l'ajouter, elle revient à ce tri "fantôme"et ajoute ensuite le N° auto.

J'ai ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
  N° Auto  | Ancien N° |
-----------|-----------|
     1     |     15    |
-----------|-----------|
     2     |     5     |
-----------|-----------|
     3     |     10    |
-----------|-----------|

Alors que je voudrais ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    N° Auto  | Ancien N° |
-----------|-----------|
     1     |     5     |
-----------|-----------|
     2     |     10    |
-----------|-----------|
     3     |     15    |
-----------|-----------|

Du coup, mon N° auto n'est pas dans le même ordre que l'ancien N°.

Pour qu'Accès tri toujours la table dans le même ordre, il doit y avoir quelque chose, quelque part.

Comme indiqué plus haut, (Merci quand même pour ce lien qui pourra me resservir), Ordres de tri appliqués en dernier (CF lien de f-leb) ne résout pas le problème.

Au moment d'ajouter le N° Auto, la table revient au tri Fantôme.

Ordres de tri par défaut (CF lien de f-leb) "uniquement [...] pour une requête ou un état".

Donc pas utilisable sur une table.

La différence entre Excel et Access, c'est qu'Excel fonctionne par cellules (du coup, bon courage si vous ratez votre tri), alors qu'Access fonctionne par enregistrements (du coup, impossible de mélanger les données).

Est-ce qu'il n’existerait pas un numéro d'enregistrement qui permettrait à Access de garder tous le contenu de tous les champs d'un même enregistrement liés entre eux (et qui servirait à faire le tri fantôme ?).

Encore une fois, chaque fois que j'ouvre cette table, elle est triée de la même manière :

Ancien N° : 66 / 18 / 19 / 20 / 21 / 22 / 112 / 96 / 113...

Toujours le 66 en premier, suivi du 18, puis du 19 etc...

Aucun autre champ n'est dans un ordre qui justifierait celui de l'ancien N°.

Cet ordre est celui qu'Access applique à la table juste avant d'ajouter le N° auto.

Pourquoi ?

Comment ?

Et, surtout, comment passer outre ?

Encore merci.

[Access_ible]

Re Bonjour.

Il m'est venu une idée, en premier lieu pour arriver à mes fins.

Mais, ce faisant, j'ai découvert un symptôme.

Je vais essayer de faire concis, pour changer…


Test 1 :

- Copier/coller de la table à trier, Structure et données (On récupère ainsi les paramétrages et descriptions de chaque champ)

- Suppression des enregistrements à la main (Ctrl+A et Suppr)

- Ajout d'un champ N° Auto

- Requête ajout des enregistrements de l'ancienne table vers la nouvelle. Dans la requête, tri croissant sur l'ancien N°


Résultats 1 :

- Le N° auto et l'ancien N° sont dans le même ordre, c'est gagné

- A l'ouverture de la nouvelle table, les enregistrements sont triés selon un ordre, toujours le même pour cette nouvelle table, pas le même que sur l'ancienne table, et toujours pas un ordre croissant.



Test 2 :

- Copier/coller de la table à trier, Structure seulement (On récupère ainsi les paramétrages et descriptions de chaque champ, et la table est vide)

- Ajout d'un champ N° Auto

- Requête ajout des enregistrements de l'ancienne table vers la nouvelle. Dans la requête, tri croissant sur l'ancien N°


Résultats 2 :

- Le N° auto et l'ancien N° sont dans le même ordre, c'est gagné

- A l'ouverture de la nouvelle table, les enregistrements sont triés selon un ordre croissant, ici correspondant vraisemblablement au N° auto. C'est doublement gagné



Symptôme :

- Une table copiée avec ses données puis vidée continue de présenter un tri fantôme. Il ne fait que changer d'ordre.

- Une table copiée sans données perd son tri fantôme (je n'ai pas de moyen de vérifier si le tri fantôme subsiste et coïncide avec le N° auto).



Épilogue :

J'ai trouvé une solution à mon problème, mais je n'ai pas d'explication à ce problème.

Personnellement, je trouve qu'on ne peut pas considérer ce problème comme résolu, car aucune explication à ce phénomène n'a été donnée ici.

Juste un moyen de contournement.

Et ce n'est peut-être même pas un problème, mais une incompréhension de ma part d'un des mécanismes d'Access.

Encore merci.

[loufab]

Bonjour,

Au risque de me répéter : Utiliser un Id comme données utilisateur est déconseillé. L'id doit uniquement servir à faire le lien entre enregistrements connexes.

C'est pourtant ce que tu indiques vouloir faire :

Il faudrait que les id soient dans l'ordre dans la table, pour que quand on trie les enregistrements par id, ils soient dans leur ordre de saisie.
C'est ici l’équivalent de lignes ou de pages numérotées dans un journal de bord.

Si on veux garder l'ordre de saisie il y a deux manières ; un champ Date/heure ou créer sa propre numérotation.
Trier un ID peut être envisagé lors d'analyse de données.

Concernant tes méthodes de duplication. Test1 est déjà à elle seule une erreur.

Si tu fais un copier/coller d'un objet table avec ses données, il copie la table et la colle d'un bloc, donc tu récupères les enregistrements dans l'ordre d'écriture dans le fichier.
Cet ordre n'a rien à voir avec l'ordre de saisie ou l'ordre des id à cause de l'optimisation de l'espace disque. Quand on écrit des données elles vont s'écrire dans la page de données (blocs de 4k consécutifs) du fichier et réoccupe des espaces libres laissés par des enregistrements supprimés.

Pourquoi le copier/coller de table n'est pas un bonne méthode :

• Lors de la copie, les blocs d'enregistrements sont pris dans l'ordre de l'écriture, placé dans le presse-papier windows.
• Lors du coller ils sont réécris dans le même ordre dans le fichier.

C'est pour cela que tu vois tes id dans un ordre de tri qui t'échappe.

Avec des volumes de données conséquents ça prendre 10 fois plus de temps qu'un INSERT INTO qui ferait le même job et qui lui :

1. Ne passe pas par le presse-papier mais reste interne au moteur SGBDR
2. Et peut être trié

Donc insert into plutôt que copier/coller.
Ne pas s'occuper des Id, il ne sont qu'un moyen de liaison.

Cordialement,

[f-leb]

Bonjour,

[...] tri fantôme

Les tris "fantômes", ça n'existe pas

Mais comme tu le sais déjà, les lignes d'une table Access ne sont pas comme les lignes numérotées d'Excel (certains y voient l'analogie d'un sac de billes).
Autrement dit, pour sortir des lignes triées, il faut une clause de tri explicite (ORDER BY au niveau SQL). Sans clause de tri, il n'y a pas de tri, même si les lignes peuvent apparaître triées selon une logique, l'ordre d'affichage n'est pas garanti et il peut se passer n'importe quoi.

Comme l'a dit loufab, un INSERT INTO avec une clause de tri explicite devrait régler le problème :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
INSERT INTO nouvelle_table(ancien_num)
SELECT ancien_num FROM ancienne_table ORDER BY ancien_num

[Access_ible]

Bonjour.

Bonjour,
[…]
Cet ordre n'a rien à voir avec l'ordre de saisie ou l'ordre des id à cause de l'optimisation de l'espace disque. Quand on écrit des données elles vont s'écrire dans la page de données (blocs de 4k consécutifs) du fichier et réoccupe des espaces libres laissés par des enregistrements supprimés.
[…]
C'est pour cela que tu vois tes id dans un ordre de tri qui t'échappe.

Et bin voilà, ça, c'est l'explication du fait que, quand j'ouvre la table, les enregistrements apparaissent triés tout le temps dans le même ordre.

Je suppose que quand j'ouvre la table, les données sont lues dans l'ordre des blocs.

Et c'est en même temps la réponse que je cherchais. Il n'est vraisemblablement pas possible de modifier cet ordre (puisque cela nécessiterait de modifier l'ordre des blocs).

Merci.

[…]
Donc insert into plutôt que copier/coller.
[…]
Cordialement,

Bonjour,
[…]
Comme l'a dit loufab, un INSERT INTO avec une clause de tri explicite devrait régler le problème :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
INSERT INTO nouvelle_table(ancien_num)
SELECT ancien_num FROM ancienne_table ORDER BY ancien_num

Heueueueu…

En quoi est-ce différent de mon test 2 décrit plus haut (que j'ai retenu comme solution puisqu'il arrive au résultat qui m'intéresse)

Bonjour,
Les tris "fantômes", ça n'existe pas

Mince, les tris "farfadets" alors ?

Mais comme tu le sais déjà, les lignes d'une table Access ne sont pas comme les lignes numérotées d'Excel (certains y voient l'analogie d'un sac de billes)…
[…]

J'aime bien l'analogie entre Excel et le sac de billes… Toutes les cellules ont leur indépendance.

À ce moment-là, Access serait du Mikado : même avec des enregistrements en vrac, les données d'un même enregistrement restent sur une même ligne, comme les anneaux de couleur sur les baguettes de Mikado.

Encore merci.

[loufab]

Bonjour,

Je suppose que quand j'ouvre la table, les données sont lues dans l'ordre des blocs.

Dans l'ordre de création des enregistrements. C'est pour cela qu'on considère qu'une table n'est pas ordonnée. C'est le rôle de la requête de faire le job de tri.

En quoi est-ce différent de mon test 2 décrit plus haut (que j'ai retenu comme solution puisqu'il arrive au résultat qui m'intéresse)

Faire un copier/coller de structure, puis tu fais un insert trié.

VS.

Exécuter une simple instruction SQL.

Pour moi la différence saute aux yeux.
Mais si tu ne vois pas voici mon avis : Pourquoi s'emm...er à faire des manips inutiles quand une simple commande SQL fait l'intégralité du job.
La solution la plus simple n'est-elle pas la meilleure ?

Cordialement,

[Access_ible]

Bonjour.

Juste pour être sûr, j'ai tenté l'expérience comme maintes fois proposé dans cette discussion...

J'ai donc reporté le code suivant dans la partie SQL du générateur de requête (Je ne sais pas où utiliser le SQL tel quel ailleurs).

Bonjour,
[...]

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
INSERT INTO nouvelle_table(ancien_num)
SELECT ancien_num FROM ancienne_table ORDER BY ancien_num

J'ai remplacé les données que j'ai identifiées :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
INSERT INTO nouvelle_table(Mon_Ancien_Num)
SELECT Mon_Ancien_Num FROM Mon_Ancienne_Table ORDER BY Mon_Ancien_Num

En mode consultation, j'ai juste une colonne avec Mon_Ancien_Num qui s'affiche dans l'ordre croissant.

Quand je clique sur "exécuter", Access m'indique :

"Impossible de trouver la table de destination "nouvelle_table" ".

Je suppose que j'ai raté quelque chose...

Encore merci.

[loufab]

En effet l'instruction de création d'une table est celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT col1,.., colx INTO ma_nouvelle_table
FROM mon_ancienne_table
ORDER BY mon_ancienne_table.colz;

INSERT INTO c'est pou l'ajout dans une table déjà créée.

[Access_ible]

Bonjour

[...]
INSERT INTO c'est pou l'ajout dans une table déjà créée.

Comme dans mon test 2 du coup...
Encore merci

[loufab]

Bonjour,

Mais, plutôt, de comprendre pourquoi ce qui se produit se produit et si il est possible de contourner cette situation.

Est-ce que tu as eu la réponse à ta question ?

Cordialement,