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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michel__D
Bonjour,
"Telesphore" a écrit dans le message de 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?
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.
Bonjour,
"Telesphore" <PleaseNoSpam@NoSpam.net> a écrit dans le message de news:e%23CH5YaAJHA.4312@TK2MSFTNGP02.phx.gbl...
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.
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
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" a écrit dans le message de 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.
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" <PleaseNoSpam@NoSpam.net> a écrit dans le message de news:
e%23CH5YaAJHA.4312@TK2MSFTNGP02.phx.gbl...
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.
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" a écrit dans le message de 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.
Telesphore
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" a écrit dans le message de 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.
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" <PleaseNoSpam@NoSpam.net> a écrit dans le message de
news:e%23CH5YaAJHA.4312@TK2MSFTNGP02.phx.gbl...
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 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" a écrit dans le message de 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
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.
"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.
"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.
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" a écrit dans le message de 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.
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" <home@sweet_home.be> a écrit dans le message de
news:%23JomYruAJHA.4052@TK2MSFTNGP06.phx.gbl...
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.
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" a écrit dans le message de 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.
