Doublons de numauto, est ce un bug?

**Simplifi** · 28/10/2010, 12h00

Bonjour à tous,
j'ai bien cherché sur ce forum, dans les FAQ et un peu partout, je n'arrive pas à trouver la solution facile à ce pb (peut être suis je passé a coté) (j'ai quand même une solution difficile à appliquer)
Table dans base joionte, c'est juste la même table aux formats mdb et accdb.
Voilà: une table d'adresses a un numéro auto, la clef est multiple et porte sur le numéro client et sur le numéro de l'adresse chez le clientex adresse 1 du client 1234 pius adresse 2 du même client etc.
le numauto sert à préciser à quelle adresse on envoie le document (devis, facture, etc)
Symptomes:
le numauto max et 12514 le nouveau est 12510 donc création de doublonset problèmes.
- j'ai essayé de supprimer les 5 lignes de 12510 à 12514, et de les recoller. elle se numérotent correctement et la suivante devient bien 12515 bonheur? Compactage de base et malheur le nouveau se retrouve à 12510
- j'ai essayé en accdb, même résultat
- j'ai essayé de créer les doublons jusqu'à ce que le nouveau soit à 12515, ok! compactage ok!!! suppression des doublons (un seul sur les deux) et compactage: perdu le nouveau revient à 12510
- j'ai essayé

Code :

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

ALTER table Adresses_clients ALTER N°_adresse COUNTER(12515,1)

dans une requête que j'ai exécuté (merci le forum) Ok, le nouveau est bien à 12515, compactage: perdu le nouveau revient à 12510

j'ai essayé de ne laisser que quelques lignes pour que le fichier joint soit plus léger, le pb disparaît, mais mes adresses aussi!!!

Alors bien sûr, je peux vider ma table dans une autre, ou bien passer le numauto en numérique entier long et travailler le vb pour l'incrémenter (c'est ce que je fais depuis déjà longtemps mais cette base est vielle et je veux surtout la dépanner en urgence)
je peux aussi passer le numauto en numérique, ajouter un nouveau numauto, créer des requêtes de mise à jour pouur toutes les utilisations hors intégrité référentielle de ce champ, et ensuite supprimer l'ancien numauto bordellique, mais la manip est longue, risquée, surtout au téléphone....

**Richard_35** · 28/10/2010, 12h25

Bonjour Simplifi,

Ton champ N°_adresse est-il la clé primaire ?

**Simplifi** · 28/10/2010, 13h09

Hello
non le N°_adresse n'est pas la clef primaire, mais

la clef est multiple et porte sur le numéro client et sur le numéro de l'adresse chez le clientex adresse 1 du client 1234 pius adresse 2 du même client etc

précision: j'ai aussi essayé de spécifier sans doublons mais dans ce cas, j'ai le message d'enregistrement impossible dès la frappe....

**Richard_35** · 28/10/2010, 13h26

J'ai téléchargé ta base .mdb

Bizarre, chez moi, le compactage ne perd pas la nouvelle séquence après lancement du SQL UPDATE.

Peux-tu vérifier sur ta base de test ?

**Simplifi** · 28/10/2010, 15h10

hello
par espoir que le téléchargement y fasse quelque chose, j'ai moi aussi téléchargé ma propre base et ré essayé le SQL.
Dès le SQL exécuté, le nouveau numéro est bien à 12515
mais après compactage, on retrouve le nouveau numéro à 12510

Précision: version Access 2010
je vais essayer sur un vieux PC

**Richard_35** · 28/10/2010, 15h22

Tu as bien essayé sur le .mdb (et non pas sur .accdb) ?

**Simplifi** · 28/10/2010, 16h19

Oui, j'ai bien essayé sur le .mdb
Depuis tout à l'heure, j'ai essayé sur mon vieux PC qui a Access 2002 ! ! !
la base telle quelle donne un nouveau à 12510, une fois passée la requête et même après compactage, on a bien les nouveau numéros 12516, 17, etc

remontée sur Access 2010, tant qu'on a pas compacté, on a la suite 12518, 19, etc
Après compactage, on retrouve le nouveau à 12510 ! ! ! !

[Edit] et même après avoir rajouté la ligne 12516 (en faisant un certain nombre d'insertions suivies d'esc-esc) la numauto continue à 12517
Après compactage, on retrouve le nouveau à 12510 ! ! ! ! (Et le matou revient, il est toujours vivant... vieille chanson de Graeme Allwright)

**Richard_35** · 28/10/2010, 16h24

Le compactage Access 2010 se comporte donc autrement que celui de 2003.

Peut-être faut-il appliquer un service pack Office 2010 qui corrigerait ce problème. Possèdes-tu le dernier SP Access 2010 ?

**f-leb** · 28/10/2010, 16h51

Bonjour,

pour info j’ai essayé à mon tour avec la base accdb (avec ma version 2007).
La numérotation commence en effet à 12510 (bug), je passe l’ALTER TABLE pour commencer à 12515.
Je reviens dans la table, la numérotation reprend bien à 12515 comme prévu.

Je compacte, je rentre quelques lignes, je re-compacte etc…

Rien à faire ! La numérotation se poursuit normalement

, 12516, 12517, etc…