Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Microsoft Office Access Access 2003 - enregistrement que l'on ne peut plus supprimé

Access 2003 - enregistrement que l'on ne peut plus supprimé

9 réponses
Avatar
thomas
Bonjour,

Dans une table, pour une raison que j'ignore un enregistrement était abimé.
Des caractères spéciaux dans les champs, des clés en numéro auto avec un
numéro égal à 65536.

L'enregistrement ne pouvait pas être supprimé du fait des relations. j'ai
supprimé les relations et recopié les bons enregistrements dans un autre
table

A quoi peut-être dû ce problème? Y-a-t-il un moyen de réparer? Comment faire
si la clé de la table avait été copiée dans d'autres tables?

Merci
Signaler un problème avec ce contenu

9 réponses

Supprimer
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
Avatar
Gloops
Bonjour,

Est-ce qu'Access (ou Windows) ne se serait pas planté au moment où on
cherchait à créer ou modifier cet enregistrement ?

Pour un numéro auto dépassant son "plafond", j'aurais tendance à di re
qu'on a créé plus d'enregistrements qu'on ne s'y attendait, non ?

Pour les caractères spéciaux dans les champs où ils n'ont pas lieu
d'être, j'aurais tendance à renvoyer à ma première question -il e st vrai
que dans ce cas le numéro auto n'est pas à l'abri de recevoir un
caractère spécial, par exemple FFFF en hexa, soit 65536.

Là, il va falloir se référer à son modèle opérationnel de don nées
(établi pendant l'analyse -je me réfère au vocabulaire Merise mais on a
pu établir un équivalent avec une autre méthode), et voir quelles t ables
sont susceptibles d'être impactées, pour corriger l'erreur à la mai n.

Bien noter un maximum d'informations sur l'état de la machine et des
autres fenêtres, et a fortiori d'Access, au moment de l'incident
(j'aurais tendance à dire du plantage car j'ai tendance à privilégi er
cette hypothèse), ce qui permettra si le problème se repose d'établ ir
des analogies et peut-être de mieux comprendre ce qui a pu bousculer le
jeu de quilles. Parmi les choses à noter : essayait-on d'imprimer un
document, sur quelle imprimante et avec quel pilote, l'imprimante
était-elle branchée et fonctionnait-elle ? Un autre périphérique
était-il en cours d'utilisation et fonctionnait-il bien ? A-t-on
remarqué d'autres anomalies sur la machine ? L'observateur d'événem ents,
dans le panneau de configuration, peut apporter un éclairage sur cette
dernière question.

Ceci est aussi une illustration de plus de l'intérêt de réaliser tr ès
régulièrement des sauvegardes. Il peut en effet arriver, si les autre s
tentatives échouent, que la seule proposition qu'on puisse avancer en
réponse soit de repartir de la sauvegarde.

Avant de toucher à la sauvegarde, il est toujours préférable de
commencer par comprendre ce qui se passe. A défaut, effectuer une copie
de la sauvegarde sur une autre machine. On a déjà vu des lecteurs
défaillants, qui effaçaient la sauvegarde au moment où on cherche à la
lire, et avaient aussi provoqué l'incident ayant motivé le recours à la
sauvegarde. Heureusement, ce n'est pas tous les jours.


Autre façon de répondre : on peut supprimer la clause d'intégrité
référencielle le temps de remettre d'aplomb les enregistrements, et l a
recréer après. Enfin là, je n'ai rien dit, hein -pas au courant.
_____________________________________
thomas a écrit, le 04/07/2008 19:36 :
Bonjour,

Dans une table, pour une raison que j'ignore un enregistrement était abimé.
Des caractères spéciaux dans les champs, des clés en numéro aut o avec un
numéro égal à 65536.

L'enregistrement ne pouvait pas être supprimé du fait des relations . j'ai
supprimé les relations et recopié les bons enregistrements dans un autre
table

A quoi peut-être dû ce problème? Y-a-t-il un moyen de réparer? Comment faire
si la clé de la table avait été copiée dans d'autres tables?

Merci




Avatar
3stone
Salut,

"thomas"
| Dans une table, pour une raison que j'ignore un enregistrement était abimé.
| Des caractères spéciaux dans les champs, des clés en numéro auto avec un
| numéro égal à 65536.


Ah! Et ce numéro devrait être magique ? ;-)

Pour information, un NuméroAuto est un entier long, donc codé sur 32 bits


| L'enregistrement ne pouvait pas être supprimé du fait des relations. j'ai
| supprimé les relations et recopié les bons enregistrements dans un autre
| table
|
| A quoi peut-être dû ce problème? Y-a-t-il un moyen de réparer? Comment faire
| si la clé de la table avait été copiée dans d'autres tables?

Par contre, une corruption fait partie des chose qui peuvent arriver...

Suppression de l'enregistrement après avoir supprimer "ses fils" et/ou
l'importation dans une nouvelle base vide sont alors conseillé.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Avatar
thomas
65536 c'était la valeur dans 2 champs en lien avec d'autres tables
Le compteur auto était à 53870604 alors qu'il n'y avait pas plus de 400
enregistrements

La situation au moment de l'enregistrement? impossible, la sauvegarde de la
veille avait le même problème

j'ai corrigé l'erreur à la main mais j'aurais aime comprendre à quoi cela
était dû pour l'éviter pour l'avenir


"Gloops" a écrit dans le message de groupe de
discussion :
Bonjour,

Est-ce qu'Access (ou Windows) ne se serait pas planté au moment où on
cherchait à créer ou modifier cet enregistrement ?

Pour un numéro auto dépassant son "plafond", j'aurais tendance à dire
qu'on a créé plus d'enregistrements qu'on ne s'y attendait, non ?

Pour les caractères spéciaux dans les champs où ils n'ont pas lieu
d'être, j'aurais tendance à renvoyer à ma première question -il est vrai
que dans ce cas le numéro auto n'est pas à l'abri de recevoir un
caractère spécial, par exemple FFFF en hexa, soit 65536.

Là, il va falloir se référer à son modèle opérationnel de données
(établi pendant l'analyse -je me réfère au vocabulaire Merise mais on a
pu établir un équivalent avec une autre méthode), et voir quelles tables
sont susceptibles d'être impactées, pour corriger l'erreur à la main.

Bien noter un maximum d'informations sur l'état de la machine et des
autres fenêtres, et a fortiori d'Access, au moment de l'incident
(j'aurais tendance à dire du plantage car j'ai tendance à privilégier
cette hypothèse), ce qui permettra si le problème se repose d'établir
des analogies et peut-être de mieux comprendre ce qui a pu bousculer le
jeu de quilles. Parmi les choses à noter : essayait-on d'imprimer un
document, sur quelle imprimante et avec quel pilote, l'imprimante
était-elle branchée et fonctionnait-elle ? Un autre périphérique
était-il en cours d'utilisation et fonctionnait-il bien ? A-t-on
remarqué d'autres anomalies sur la machine ? L'observateur d'événements,
dans le panneau de configuration, peut apporter un éclairage sur cette
dernière question.

Ceci est aussi une illustration de plus de l'intérêt de réaliser très
régulièrement des sauvegardes. Il peut en effet arriver, si les autres
tentatives échouent, que la seule proposition qu'on puisse avancer en
réponse soit de repartir de la sauvegarde.

Avant de toucher à la sauvegarde, il est toujours préférable de
commencer par comprendre ce qui se passe. A défaut, effectuer une copie
de la sauvegarde sur une autre machine. On a déjà vu des lecteurs
défaillants, qui effaçaient la sauvegarde au moment où on cherche à la
lire, et avaient aussi provoqué l'incident ayant motivé le recours à la
sauvegarde. Heureusement, ce n'est pas tous les jours.


Autre façon de répondre : on peut supprimer la clause d'intégrité
référencielle le temps de remettre d'aplomb les enregistrements, et la
recréer après. Enfin là, je n'ai rien dit, hein -pas au courant.
_____________________________________
thomas a écrit, le 04/07/2008 19:36 :
Bonjour,

Dans une table, pour une raison que j'ignore un enregistrement était
abimé.
Des caractères spéciaux dans les champs, des clés en numéro auto avec un
numéro égal à 65536.

L'enregistrement ne pouvait pas être supprimé du fait des relations. j'ai
supprimé les relations et recopié les bons enregistrements dans un autre
table

A quoi peut-être dû ce problème? Y-a-t-il un moyen de réparer? Comment
faire
si la clé de la table avait été copiée dans d'autres tables?

Merci




Avatar
thomas
dans ce cas particulier le numéro auto n'était pas enregistré dans d'autres
tables, donc pas trop de dégats

mais que faire si il l'avait été?

l'importation dans une autre table aurait attribué un nouveau numéro au
numéro auto et cassé la relation

j'aurais pu garder le même numéro auto? importé les valeurs de ce champ dans
un champ auto et le rendre auto ensuite?

merci


"3stone" a écrit dans le message de groupe de
discussion : #
Salut,

"thomas"
| Dans une table, pour une raison que j'ignore un enregistrement était
abimé.
| Des caractères spéciaux dans les champs, des clés en numéro auto avec un
| numéro égal à 65536.


Ah! Et ce numéro devrait être magique ? ;-)

Pour information, un NuméroAuto est un entier long, donc codé sur 32 bits


| L'enregistrement ne pouvait pas être supprimé du fait des relations. j'ai
| supprimé les relations et recopié les bons enregistrements dans un autre
| table
|
| A quoi peut-être dû ce problème? Y-a-t-il un moyen de réparer? Comment
faire
| si la clé de la table avait été copiée dans d'autres tables?

Par contre, une corruption fait partie des chose qui peuvent arriver...

Suppression de l'enregistrement après avoir supprimer "ses fils" et/ou
l'importation dans une nouvelle base vide sont alors conseillé.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Avatar
Gloops
thomas a écrit, le 05/07/2008 20:35 :
dans ce cas particulier le numéro auto n'était pas enregistré dan s d'autres
tables, donc pas trop de dégats

mais que faire si il l'avait été?

l'importation dans une autre table aurait attribué un nouveau numér o au
numéro auto et cassé la relation

j'aurais pu garder le même numéro auto? importé les valeurs de ce champ dans
un champ auto et le rendre auto ensuite?

merci


"3stone" a écrit dans le message de groupe de
discussion : #
Salut,

"thomas"
| Dans une table, pour une raison que j'ignore un enregistrement étai t
abimé.
| Des caractères spéciaux dans les champs, des clés en numéro a uto avec un
| numéro égal à 65536.


Ah! Et ce numéro devrait être magique ? ;-)

Pour information, un NuméroAuto est un entier long, donc codé sur 3 2 bits


| L'enregistrement ne pouvait pas être supprimé du fait des relatio ns. j'ai
| supprimé les relations et recopié les bons enregistrements dans u n autre
| table
|
| A quoi peut-être dû ce problème? Y-a-t-il un moyen de réparer ? Comment
faire
| si la clé de la table avait été copiée dans d'autres tables?

Par contre, une corruption fait partie des chose qui peuvent arriver...

Suppression de l'enregistrement après avoir supprimer "ses fils" et/o u
l'importation dans une nouvelle base vide sont alors conseillé.



Avatar
Gloops
thomas a écrit, le 05/07/2008 20:35 :
j'aurais pu garder le même numéro auto? importé les valeurs de ce champ dans
un champ auto et le rendre auto ensuite?




Tiens, oui, c'est vrai que c'est intéressant ça comme question.
Si on crée une nouvelle table avec un numéro auto, en remplacement d' une
table corrompue, on est bon pour corriger toutes les clefs externes qui
y font référence.

3stone a parlé de l'importation dans une nouvelle base, c'est à teste r,
dans certains cas ça peut marcher.
Si ça ne marche pas, on en revient à l'hypothèse de travail précé dente,
corriger les clefs externes une par une.

M'est avis que si quelqu'un, cet été, a quelques "longues soirées
d'hiver" à occuper, voilà de quoi plancher. Commencer par une batteri e
de tests sur le transfert d'une table dans une nouvelle base (et pour
ça, comment faire pour corrompre la table de façon à constater le
résultat du transfert ?), et si jamais les tests ne s'avèrent pas tou s
concluants, préparer un outil qui sache repérer les enregistrements d ans
la nouvelle base et faire le rapprochement avec les clefs dans
l'ancienne, de façon à être capable de restaurer les clefs externes dans
la nouvelle base.

Ben, celui qui aura fait ça, il aura bien travaillé :)

(la première étape, j'imagine, sera de lire attentivement toutes les FAQ
; et si quelqu'un avait déjà fait ça ? C'est vrai, on devrait toujo urs
les lire avant de poser une question, enfin disons que ça peut aider de
recommencer ... ;) )
Avatar
3stone
Salut,

"thomas"
| dans ce cas particulier le numéro auto n'était pas enregistré dans d'autres
| tables, donc pas trop de dégats


Un NuméroAuto enregsitré dans une "autre" table est appelé clé externe


| mais que faire si il l'avait été?

Supprimer ce/ces champs fils....
et voir ce qui à fait dérapper la chose.


| l'importation dans une autre table aurait attribué un nouveau numéro au
| numéro auto et cassé la relation
|
| j'aurais pu garder le même numéro auto? importé les valeurs de ce champ dans
| un champ auto et le rendre auto ensuite?


Non, pas importer dans une nouvelle table !

Créer une base de données vide et importer celle qui crée problème...
Voir le menu Fichiers, Données externes, Importer...

Ceci dit, les corruptions d'une base ne vient pas "comme ca".
Soit le réseau, le manque flagrant de mémoire, des micro-coupures de courant
ou simplement la manière de faire peut être la cause.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Avatar
thomas
bon ok et merci quand même pour cette réponse "philosophique" qui ne me sera
pas d'une grande utilité


"Gloops" a écrit dans le message de groupe de
discussion :
thomas a écrit, le 05/07/2008 20:35 :
j'aurais pu garder le même numéro auto? importé les valeurs de ce champ
dans
un champ auto et le rendre auto ensuite?




Tiens, oui, c'est vrai que c'est intéressant ça comme question.
Si on crée une nouvelle table avec un numéro auto, en remplacement d'une
table corrompue, on est bon pour corriger toutes les clefs externes qui
y font référence.

3stone a parlé de l'importation dans une nouvelle base, c'est à tester,
dans certains cas ça peut marcher.
Si ça ne marche pas, on en revient à l'hypothèse de travail précédente,
corriger les clefs externes une par une.

M'est avis que si quelqu'un, cet été, a quelques "longues soirées
d'hiver" à occuper, voilà de quoi plancher. Commencer par une batterie
de tests sur le transfert d'une table dans une nouvelle base (et pour
ça, comment faire pour corrompre la table de façon à constater le
résultat du transfert ?), et si jamais les tests ne s'avèrent pas tous
concluants, préparer un outil qui sache repérer les enregistrements dans
la nouvelle base et faire le rapprochement avec les clefs dans
l'ancienne, de façon à être capable de restaurer les clefs externes dans
la nouvelle base.

Ben, celui qui aura fait ça, il aura bien travaillé :)

(la première étape, j'imagine, sera de lire attentivement toutes les FAQ
; et si quelqu'un avait déjà fait ça ? C'est vrai, on devrait toujours
les lire avant de poser une question, enfin disons que ça peut aider de
recommencer ... ;) )
Avatar
Gloops
thomas a écrit, le 05/07/2008 22:03 :
bon ok et merci quand même pour cette réponse "philosophique" qui n e me sera
pas d'une grande utilité




Bon, alors je n'ai rien dit, pas la peine que quelqu'un se lance
là-dessus ...