Doublons dans Champ primaire numéroauto

Le
Telesphore
Subitement il est impossible d'ajouter un nouvel enregistrement dans la
table tblÉtudiants.
Le champ idÉtudiant clé primaire numéroauto indique 762 enregistrements.
Le nouvel enregistrement dans le champ CodeÉtudiant devrait être le
matricule 08-1721.
Il est impossible d'enregistrer ce numéro de matricule, car le message
suivant apparaît: "Modifications non effectués, risque de doublons, etc." et
le champ primaire numéroauto idÉtudiant indique 3alors 386. Si on essaie de
nouveau, idÉtudiant indique 387, etc., sans pouvoir rien enregistrer car
386, 387 etc. sont déjà assignés automatiquement à d'anciens
enregistrements..

Sur un autre poste de travail, si on essaie d'entrer un nouvel
enregistrement, idÉtudiant indique 606

La base principale est sur un serveur Windows Server 2003: IFTM_princip.
Les usagers travaillent sur des postes de travail individuels Windows XP.

Nous avons installé le SP3, mais rien n'y fait.

Quoi faire?

Merci d'avance.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michel__D
Le #16575651
Bonjour,

"Telesphore"
Subitement il est impossible d'ajouter un nouvel enregistrement dans la
table tblÉtudiants.
Le champ idÉtudiant clé primaire numéroauto indique 762 enregistrements.
Le nouvel enregistrement dans le champ CodeÉtudiant devrait être le
matricule 08-1721.
Il est impossible d'enregistrer ce numéro de matricule, car le message
suivant apparaît: "Modifications non effectués, risque de doublons, etc." et
le champ primaire numéroauto idÉtudiant indique 3alors 386. Si on essaie de
nouveau, idÉtudiant indique 387, etc., sans pouvoir rien enregistrer car
386, 387 etc. sont déjà assignés automatiquement à d'anciens
enregistrements..

Sur un autre poste de travail, si on essaie d'entrer un nouvel
enregistrement, idÉtudiant indique 606...

La base principale est sur un serveur Windows Server 2003: IFTM_princip.
Les usagers travaillent sur des postes de travail individuels Windows XP.

Nous avons installé le SP3, mais rien n'y fait.

Quoi faire?



Si la base est scindée en 2 avec une base frontale et une base dorsale,
essaye avec l'exemplaire de la base frontale du poste de travail ou cela
fonctionne.
Goupil
Le #16575961
Salut !

J'ai eu souvent ce problème de compteur qui "recule".
Access essaye de générer un numéro qui est inférieur au plus grand, ce
numéro existe et il est refusé !
C'est assez étrange, et je pense que c'est un bug Microsoft...
Ce problème arrive en général suite à une requête ajout sur cette table,
mais ça reste mystérieux...

Solution:
Recréer la table par une requête création ou bien faire une copie de la
table (moins fiable).
Bien entendu, il faut casser l'éventuelle relation avec l'ancienne table
pour la rétablir avec la nouvelle.

Goup'


"Telesphore" e%
Subitement il est impossible d'ajouter un nouvel enregistrement dans la
table tblÉtudiants.
Le champ idÉtudiant clé primaire numéroauto indique 762 enregistrements.
Le nouvel enregistrement dans le champ CodeÉtudiant devrait être le
matricule 08-1721.
Il est impossible d'enregistrer ce numéro de matricule, car le message
suivant apparaît: "Modifications non effectués, risque de doublons, etc."
et le champ primaire numéroauto idÉtudiant indique 3alors 386. Si on
essaie de nouveau, idÉtudiant indique 387, etc., sans pouvoir rien
enregistrer car 386, 387 etc. sont déjà assignés automatiquement à
d'anciens enregistrements..

Sur un autre poste de travail, si on essaie d'entrer un nouvel
enregistrement, idÉtudiant indique 606...

La base principale est sur un serveur Windows Server 2003: IFTM_princip.
Les usagers travaillent sur des postes de travail individuels Windows XP.

Nous avons installé le SP3, mais rien n'y fait.

Quoi faire?

Merci d'avance.


Telesphore
Le #16585721
Merci à Michel et à Goupil,

Nous avons décidé de faire comme habitude de reprendre une version
antérieure de 2 jours.
Cependant je me suis rendu compte que Access a accepté un numéro auto dont
l'enregistrement avait été supprimé.
Serait-il que Access n'aime pas qu'on supprime des enregistrements?

Merci.


"Telesphore" news:e%
Subitement il est impossible d'ajouter un nouvel enregistrement dans la
table tblÉtudiants.
Le champ idÉtudiant clé primaire numéroauto indique 762 enregistrements.
Le nouvel enregistrement dans le champ CodeÉtudiant devrait être le
matricule 08-1721.
Il est impossible d'enregistrer ce numéro de matricule, car le message
suivant apparaît: "Modifications non effectués, risque de doublons, etc."
et le champ primaire numéroauto idÉtudiant indique 3alors 386. Si on
essaie de nouveau, idÉtudiant indique 387, etc., sans pouvoir rien
enregistrer car 386, 387 etc. sont déjà assignés automatiquement à
d'anciens enregistrements..

Sur un autre poste de travail, si on essaie d'entrer un nouvel
enregistrement, idÉtudiant indique 606...

La base principale est sur un serveur Windows Server 2003: IFTM_princip.
Les usagers travaillent sur des postes de travail individuels Windows XP.

Nous avons installé le SP3, mais rien n'y fait.

Quoi faire?

Merci d'avance.


3stone
Le #16586191
Salut,

"Telesphore"
| Nous avons décidé de faire comme habitude de reprendre une version
| antérieure de 2 jours.

Pas idéal comme méthode...
Si, "comme d'habitude" c'est reconnaitre que la base à fréquemment
des problèmes et il vaudrait mieux de tout faire pour les résoudre.


| Cependant je me suis rendu compte que Access a accepté un numéro auto dont
| l'enregistrement avait été supprimé.

Corruption, ou problème de prog dans la base...


| Serait-il que Access n'aime pas qu'on supprime des enregistrements?

Rien à voir... heureusement ;-)

Par contre, il est conseillé et même obligatoire de compacter régulièrement
la base et très régulièrement s'il y a beaucoup de suppression/création.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Telesphore
Le #16596301
Merci,

J'avais compacté, mais ça n'a pas réglé le problème, car il manque toujours
les numéros auto du champ idÉtudiant de la table tblÉtudiants. C'est normal,
car il y a eu 42 suppressions de noms d'étudiants depuis que la base a été
créée.

Travaillant sur la copie problématique et essayant d'ajouter un nouveau nom,
Access propose le numéro 608 dans le champ idÉtudiant. C'est un doublon,
alors je vais numéro par numéro jusqu'au numéro 627 qui sera accepté. De
même pour le numéro 628. Ces 2 numéros avaient été supprimés lors de la
suppression des enregistrements correspondants. Les prochains numéros qui
seront acceptés seront 659, 684 et 723... et puis ensuite je vais jusqu'au
numéro 763, qui lui sera accepté, car c'est un nouveau numéro.

Et voilà le problème semble être réglé... jusqu'à nouvel ordre, car il reste
encore 37 numéros auto supprimés.

Cela semble être un bug d'Access.

Voir
http://support.microsoft.com/kb/291162/fr
et
http://support.microsoft.com/kb/239114/


"3stone" news:%
Salut,

"Telesphore"
| Nous avons décidé de faire comme habitude de reprendre une version
| antérieure de 2 jours.

Pas idéal comme méthode...
Si, "comme d'habitude" c'est reconnaitre que la base à fréquemment
des problèmes et il vaudrait mieux de tout faire pour les résoudre.


| Cependant je me suis rendu compte que Access a accepté un numéro auto
dont
| l'enregistrement avait été supprimé.

Corruption, ou problème de prog dans la base...


| Serait-il que Access n'aime pas qu'on supprime des enregistrements?

Rien à voir... heureusement ;-)

Par contre, il est conseillé et même obligatoire de compacter
régulièrement
la base et très régulièrement s'il y a beaucoup de suppression/création.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)



Publicité
Poster une réponse
Anonyme