[Résolu] Fichier .odb corrompu (erreur générale E/S)

[clmnisko]

Bonjour,

Tout d'abord, merci pour votre super forum qui m'a été souvent bien utile en fouillant dans ses nombreux billets !

J'ai donc une base de données .odb que j'utilise régulièrement. Récemment, égaré dans la déconfiture du confinement (courage à tout le monde !!), j'ai juste fait une petite modif sur deux formulaires pour améliorer leur ergonomie (tri ascendant est devenu tri descendant). Sur le coup, tout allait bien et j'ai pu enregistrer comme d'habitude, mais - badaboum - quelques jours après je n'arrive plus à ouvrir mon document : Erreur générale S/E. Ma version d'Open Office Base n'est pas en cause car j'arrive toujours à ouvrir sans problème d'autres bases de données en .odb.
J'ai écumé tous les posts sur le sujet, sans succès jusqu'à maintenant.

Voici tout ce que j'ai tenté :

1. Test de mon document .odb avec TesteurCorruption.odt (merci bm92 !) qui renvoie le message suivant :

La structure zip de ce document ODF est endommagée.

2. J'ai tenté ensuite de passer mon fichier .odb dans l'outil ODFRepar_v_1_0_1 (merci Scrat ! J'ai aussi suivi le super tuto en pdf qui lui est associé) qui m'a renvoyé le message suivant :

ERREUR : invalid END header (bad central directory offset)
CE FICHIER N'A PAS DE STRUCTURE ZIP !
Échec de l'analyse !

3. J'ai donc changé l'extension de mon fichier .odb en .zip (testé avec 7zip et ZipGenius) puis ai tenté de réparer l'archive avec Zip2Fix (j'ai également réessayé les points 3 à 5 en utilisant ZipRepar).

4. J'ai ensuite re-tenté ODFRepar_v_1_0_1 avec l'archive réparée : est allé jusqu'au bout du processus (Analyser, Extraire, Réparer) mais le document (archive re-compressée puis extension .zip remplacée par .odb) est toujours corrompu. Après ouverture dans Base (les noms des formulaires s'affichent à l'accueil mais impossible de les ouvrir), j'ai le message suivant :

Impossible d'établir une connexion avec la source de données
User not found: SA

(détail de l'erreur : Statut SQL: S1000 Code erreur: -37)

5. Dans l'archive réparée, j'ai également tenté de remplacer les fichiers corrompus identifiés par ODFRepar_v_1_0_1 par ceux d'une sauvegarde de ma base de données datant de quelques jours auparavant et qui s'ouvre parfaitement (je peux envoyer ce backup si ça peut aider à la résolution). Sans succès...
Pour info, la liste (exhaustive ?) des fichiers corrompus que j'ai tenté de remplacer :

...database/backup
...Configurations2/accelerator/current.xml
...forms/obj31/Configurations2/accelerator/current.xml
...forms/obj32/Configurations2/accelerator/current.xml
...forms/obj41/Configurations2/accelerator/current.xml
...forms/obj51/Configurations2/accelerator/current.xml

Bref, quelque chose m'échappe et/ou dépasse largement mes petites compétences informatiques.
Je joins mon fichier .odb corrompu (le fichier original, bien sûr ! J'ai fait les modifs citées précédemment sur une autre copie), si vous avez un moment pour regarder svp ? https://www.cjoint.com/c/JCvoC5taBrZ
C'est une base à usage personnel, sans grande incidence sur le cours de l'Univers, mais je m'en sers souvent et j'ai fait un certain nombre d'ajouts depuis mon dernier backup, et ne pourrai pas retrouver précisément ce qui manque...

Merci d'avance pour votre aide !
Clément

P.S: En faisant mes recherches, j'ai découvert la sauvegarde incrémental : je vais désormais systématiquement le mettre en place sur mes documents Open Office, et vais scrupuleusement appliquer les conseils du post "Prévention de la corruption des fichiers .odb du module Base"...

[Scrat]

Bonjour.

J'ai essayé de réparer avec ZipRepar et ODFRepar et je suis arrivé à la même impossibilité d'ouvrir les tables.

L'utilitaire ODFRepar commence par tenter d'ouvrir le fichier en tant qu'archive zip. Dans le cas présent, les algorithmes Java échouent et il faut passer par un autre outil. Si l'ouverture est possible, l'utilitaire extrait ce qu'il peut et il essaie de réparer les fichiers xml. Si la corruption est trop sévère, il se peut que les fichiers xml réparés ne soient pas interprétables et il faut terminer la réparation à la main avec un éditeur. Quant aux fichiers xml irréparables, ils sont ignorés. Dans tous les cas l'utilitaire considère qu'il traite une archive zip et il ne vérifie pas sa cohérence en tant que base de données.

J'ai supposé que les tables contenues dans le dossier database étaient intactes, et j'ai essayé de remplacer le database d'une base test nouvellement créée par le database du fichier réparé, et toujours impossible d'ouvrir.

Je ne connais pas suffisamment la structure des bases de données pour aller plus loin. Peut-être qu'un spécialiste pourrait vous aider ?

A+

[clmnisko]

Merci Scrat pour votre réponse rapide et votre tentative de résolution !
J'espère que quelqu'un aura une idée pour essayer d'au moins récupérer la partie data du document

Bonne soirée et prenez soin de vous et de vos proches en ces temps difficiles,
Clément

[jeanmimi]

Bonjour,
Les data sont toujours dans le sous-module. Par contre, le poids de 1,4 Mo a pu causer la corruption de la Base (due à des images ou des photos ?).

Poids_data_MesPetitesPlantes.jpg

J'ai supposé que les tables contenues dans le dossier database étaient intactes, et j'ai essayé de remplacer le database d'une base test nouvellement créée par le database du fichier réparé, et toujours impossible d'ouvrir.

La méthode décrite par Scrat sur ce seul fichier data pourrait être tentée.

[OOotremer971]

Bonjour,

J'espère que quelqu'un aura une idée pour essayer d'au moins récupérer la partie data du document

j'ai essayé de remplacer le database d'une base test nouvellement créée par le database du fichier réparé, et toujours impossible d'ouvrir.

Pas la peine d'insister, le fichier data du sous répertoire database est complètement illisible. Les quelques lignes du début sont à peu près correctes mais le reste est bouillie

Data_OK.png

Data_OK2.png

et enfin la bouillie :

Data_NOK.png

Désolé

[micmac]

Bonjour,

Fichier perdu = sujet résolu
Merci de baliser. Comment clore correctement un sujet lorsqu'il est résolu.
Relisez nos conseils afin que cela ne se reproduise plus.

Cordialement

[clmnisko]

Merci quand même d'avoir essayé, jeanmimi et OOotremer971 !

Pour info, il n'y avait aucune image dans cette base. Uniquement données texte et chiffres.
Vais désormais appliquer les préconisations d'entretien des fichiers Base, et envisager une solution plus stable qu'Open Office pour ce genre d'usage...

Je clos le billet, bonne soirée et encore merci,
Clément

[CanadaDry]

Hello,


Qu'as-tu bien pu faire dans le fichier ?
On voit qu'entre le backup et la base actuelle, elle a triplé de taille.

[clmnisko]

Bonsoir CanadaDry,

Je n'ai vraiment rien fait de spécial, c'est bien ça qui m'étonne !
Comme mentionné dans mon 1er billet, j'ai juste modifié deux formulaires de la base de données. Si vous voulez plus de détails : ces formulaires contenaient chacun un SubForm listant les entrées existantes du formulaire (filtrées selon un critère envoyé par le formulaire)... La modification en question a juste consisté à passer le tri de ce SubForm d'ascendant à descendant (pour faciliter la lisibilité).
Ce fut sans doute la manip' de trop sur un document dont j'ignorais qu'il fallait régulièrement compacter la base (cf billet "
Prévention de la corruption des fichiers .odb" https://forum-test.openoffice.org/fr/fo ... =9&t=30518)...

Bonne soirée à vous,
Clément

[CanadaDry]

Re-hello,

j'ai juste modifié deux formulaires de la base de données.

Quand on modifie la structure (table, formulaire ou édition), il faut travailler sur une copie et pas sur ce qui est en production.
Cela vaut pour toutes les bases de données.

Et cela évitera d'avoir les yeux dans l'eau après.