Comment réparer une corruption de base de données possible?

Question

Je suis chez un client en train de corriger rapidement leur application d'accès. Cela faisait un moment que j'avais un accès avec accès, mais je récupère rapidement. Cependant, j'ai découvert un problème intéressant:

Pour certains rapports, le message "L’enregistrement est supprimé". Erreur. J'ai vérifié les rapports et il semble qu'il y ait un problème avec une table. En ouvrant cette table, je trouve un enregistrement dans lequel toutes les colonnes sont marquées "# supprimé". Donc, évidemment, cette ligne semble être le coupable. Cependant, lorsque j'essaie de supprimer cette ligne, rien ne se passe vraiment. Si je rouvre la table, la ligne existe toujours.

Y a-t-il une corruption dans la base de données? Comment puis-je supprimer ce disque pour de bon?

Modifier: c'est une version MS2000

Solution: Simplement compresser / réparer ne fonctionne pas. J'ai converti la base de données au format de fichier 2003 à la place, ce qui a fait l'affaire. J'ai marqué la première réponse en suggérant compresser / réparer, car elle m'a orienté dans la bonne direction. Merci!

Answer 1

Avez-vous essayé l'outil de réparation / compactage Access intégré? Cela devrait vider les enregistrements supprimés de la base de données.

L'emplacement exact varie en fonction de la version d'Access utilisée, mais sous Access 2003, il se trouve sous Outils > Utilitaires de base de données > Compacter et réparer la base de données. Certaines versions précédentes d’Access comportaient deux outils distincts, l’un pour les compactes et l’autre pour les réparations, mais elles étaient accessibles à partir d’un emplacement similaire. S'ils sont distincts dans la version du client, vous devez exécuter les deux.

Cela devrait être une opération non destructive, mais il serait préférable de le tester sur une copie du fichier MDB (excuses pour avoir déclaré l'évidence).

Answer 2

Tony Toews, Access MVP, dispose d’un guide complet sur la corruption:

FAQ sur la corruption des MDB Microsoft Access

• Certains symptômes de corruption
• Détermination du poste de travail ayant causé la corruption
• Les causes de la corruption
• Pour récupérer vos données

En passant, la decompile est très utile pour résoudre les événements les plus étranges. lors du codage et pour améliorer les temps de démarrage.

Answer 3

vous pouvez également essayer cet utilitaire de ligne de commande

// andy

Answer 4

Le compactage et l’importation ne résoudront pas le problème de l’erreur signalée, qui est clairement un pointeur corrompu pour un champ Mémo. La seule chose que vous pouvez faire est de supprimer et de recréer l'enregistrement à l'origine du problème. Et vous devez trouver des moyens de modifier les données de mémo (ou d'éliminer les champs de mémo - avez-vous vraiment besoin de plus de 255 caractères ou non?) Sans vous exposer au risque de corruption. Cela signifie éviter les contrôles liés sur les formulaires pour les champs de mémo.

Utilisez plutôt une zone de texte non liée et, dans l'événement OnCurrent du formulaire, affectez les données actuelles à partir de la source d'enregistrements sous-jacente du formulaire:

  Me!txtMyMemo = Me!MyMemo

Pour enregistrer les modifications apportées au contrôle indépendant, utilisez l'événement AfterUpdate du contrôle:

  Me!MyMemo = Me!txtMyMemo
  Me.Dirty = False        ' save the whole record

Pourquoi les champs de mémo sont-ils sujets à la corruption? Parce qu'elles ne sont pas stockées dans la même page de données que les champs non mémo, mais tout ce qui se trouve dans la page de données principale de l'enregistrement est un pointeur sur une autre page de données (ou un ensemble de pages de données s'il s'agit d'un gros bloc de données). données) où les données mémo réelles sont stockées. Si tel n’était pas le cas, un enregistrement contenant une note dépasserait très rapidement la longueur maximale de l’enregistrement.

Le pointeur est relativement facilement corrompu, le plus souvent par un problème fatal lors de la modification dans un contrôle dépendant. L'édition avec un contrôle non lié n'élimine pas entièrement le problème, mais signifie que le temps d'exposition au danger est très très court (c'est-à-dire le temps nécessaire à l'exécution de ces deux lignes de code dans l'événement AfterUpdate). .

Answer 5

Outre les options déjà publiées ci-dessus, j’utilise une autre méthode simple: créez simplement un nouveau fichier MDB et importez tous les objets du fichier corrompu. N'oubliez pas d'obtenir des objets système et / ou cachés lorsque vous vous y rendrez.