[HS] Table vide après sauvegarde via Cobian

[Aigle bavard]

Bonjour,
Avec le logiciel de sauvegarde appelé Cobian Backup 11, je lance une sauvegarde de mon répertoire contenant ma base de données (table +formulaire) depuis mon disque E: vers un second disque F:

Lorsque je veux ouvrir cette base de données sur le disque F: pour la vérifier, le formulaire m'oppose que la table est vide.

Sorcellerie ?

Merci.

[Dude]

Salut,

Merci d'éviter les anglicismes dans les titres, ainsi que les termes implicites.
Par exemple, Sauvegarde avec programme Cobian Backup semble plus adapté.

+1
Merci de faire ce que te demande le modo pour continuer à recevoir des réponses.

je lance une sauvegarde de mon répertoire contenant ma base de données (table +formulaire)

Bien entendu pour ce genre d'opération, l'ODB ne doit pas être ouvert.

[Aigle bavard]

je lance une sauvegarde de mon répertoire contenant ma base de données (table +formulaire)

Bien entendu pour ce genre d'opération, l'ODB ne doit pas être ouvert.

Bien entendu...
Mais je subodore que le formulaire embarque un lien de chemin absolu de ses champs vers la table originale, et que ce lien ne correspond plus dès que le chemin de l'unité est modifié.

Merci de ne pas citer l'intégralité des messages, l'essentiel suffit pour ne pas alourdir la lecture

[Dude]

Mais je subodore que le formulaire embarque un lien de chemin absolu de ses champs vers la table originale

Par défaut les formulaires sont dans l'ODB et si tu utilises le format natif HSQL, les tables le sont également.



Donc merci de fournir un ODB qui permette de reproduire ce que tu décris.

.

[jeanmi2403]

Bonsoir,

je lance une sauvegarde de mon répertoire contenant ma base de données (table +formulaire) depuis mon disque E: vers un second disque F:

Ca laisse supposer que tout n'est pas dans le fichier ODB ?
Avec une table externe (feuille Calc, par exemple), pas étonnant, à moins que ça ne soit le formulaire qui est externe ?

le formulaire m'oppose que la table est vide.

Et elle est vide ou non ?
Bonne soirée,

[Aigle bavard]

Non, avec la sauvegarde, la table est vide.
Mais avec une simple copie du fichier odb, même sur une autre unité, ça fonctionne parfaitement.
Il semble que le logiciel de sauvegarde ajoute sa sauce perso qui pose problème.

[jeanmi2403]

Bonsoir,

Il semble que le logiciel de sauvegarde ajoute sa sauce perso qui pose problème.

Il se peut que ce logiciel détecte la structure du fichier (qui est en fait un ZIP) et qu'il bricole des choses pas catholiques à l'intérieur...
Cordialement,

[Aigle bavard]

Les poids sont identiques (donc pas de compression ZIP) mais il est en effet possible qu'un flag soit différent (bien que le fichier sauvegardé s'ouvre directement dans Libre Office avec un double-clic, sans message de protestation)
Empiriquement, il semble donc que pour conserver un double de sécurité d'une base de données OO ou LibreOffice, il vaut mieux procéder par simple copie de fichier que par sauvegarde via un logiciel spécialisé.

[tintin]

Bonjour,

[...] il vaut mieux procéder par simple copie de fichier que par sauvegarde via un logiciel spécialisé.

ou utiliser l'excellente extension de sauvegarde incrémentale d'Alain de La Chaume

[Aigle bavard]

J'ai préféré opter (déformation professionnelle) pour une copie sur une unité différente (HDD externe éteint en fonctionnement normal et allumé seulement au moment de la copie de sécurité, hors connexion internet ou réseau local).

[Dude]

il vaut mieux procéder par simple copie de fichier que par sauvegarde via un logiciel spécialisé

Cobian fait de la copie programmée.
Et un ODB peut parfaitement être sauvegardé de cette façon.

Bis repetitae :

Donc merci de fournir un ODB qui permette de reproduire ce que tu décris.

Tu nous joins l'ODB d'origine et celui sauvegardé.

[Aigle bavard]

Certainement mais programmée ou non, ce n'est pas du tout le problème.
Le problème est dans l'exploitation de la base (table+formulaire) sauvegardé par Cobian Backup. Quel que soit le mode de sauvegarde.

Mais comme je l'ai déjà indiqué, j'ai résolu mon problème par une simple copie.

[jeanmi2403]

Bonjour,

Les poids sont identiques

A l'octet près ?

(donc pas de compression ZIP)

Un odb (odf en général) est en fait un fichier compressé, avec une structure de dossiers à l'intérieur. Il suffit de changer son extension en zip et de fouiller dedans pour s'en rendre compte...

Il semble que le logiciel de sauvegarde ajoute sa sauce perso qui pose problème.

Et Cobian a tout un tas d'options (cryptage, 7-zip, etc...).
Comme dit Dude, envoie les deux fichiers, qu'on puisse comparer les contenus une fois dézippés...

Mais comme je l'ai déjà indiqué, j'ai résolu mon problème par une simple copie

Alors, tu peux baliser [Résolu], mais le problème reste entier, et j'aimerais comprendre..
Cordialement,

[Aigle bavard]

La base est confidentielle, hélas. Elle ne concerne pas que moi, je ne peux pas en disposer ni la communiquer.
La version native et la version sauvegardée (Cobian sans compression) sont égales à l'octet près.
La version sauvegardée annonce une table vide.
La même version (au même endroit) par simple copie fonctionne parfaitement.

[Dude]

La base est confidentielle, hélas.

On ne demande pas l'ODB original mais un exemple débarrassé des données confidentielles.

[Aigle bavard]

Alors "on" devrait savoir que la structure et le nom des champs sont déjà des informations.

[Dude]

Alors "on" devrait savoir que la structure et le nom des champs sont déjà des informations.

Bis repetitae : "on" ne te demande pas la vraie base.
Tu fabriques un ODB qui reproduit le problème avec une table dont les champs sont également anonymisés.
Il y a même fort à parier qu'en faisant cet exercice, tu trouves toi-même la cause du dysfonctionnement.

[Aigle bavard]

J'ai créé une table avec son formulaire (différente de ma table originale) et le même problème se produit lorsque je la sauvegarde sur une unité différente avec Cobian Backup1 11.2.0.582 : "Impossible de charger le contenue des données, la table «SVGTest1» n'existe pas".
Il semble que le logiciel sauvegarde le formulaire mais pas la table (phénomène qui ne se produit pas par une simple copie).
Pourtant, toutes les options de compression/cryptage sont désactivées.

[Aigle bavard]

Observation :
Si je lance la sauvegarde en la laissant aller dans son répertoire reproduisant le chemin UNC de l'unité d'origine, le fichier sauvegardé ne retrouve pas la table mais seulement le formulaire.
Si je lance la sauvegarde du fichier SVGTEst1.odb depuis
E:\Annexe\Mes documents\Mes sources de données\Perso
vers
F:\SVGTest1.odb (donc, juste la racine) alors la sauvegarde retrouve bien la table associée au formulaire.

[Aigle bavard]

Paramétrage de Cobian (mais je ne sais pas si ce sera lisible)

Param1_SVGodb.jpg

[Aigle bavard]

Je n'ai plus d'éditeur hexa (j'ai quitté le métier) mais, de toute façon parcourir l'intégralité des fichiers sauvegardés pour y retrouver un chemin absolu serait rédhibitoire.
Toutefois, je soupçonne que c'est ce qui se passe : le chemin UNC est mémorisé par la sauvegarde et il le remontera pour retrouver la table associée au formulaire.
Ce type de sauvegarde ne serait donc fonctionnel que si le fichier est restauré à sa place originale.
C'est logique mais ça empêche la vérification de l'intégrité de la base sauvegardée avant sa restauration.
On ne peut vérifier qu'en restaurant (c'est à dire lorsque la sauvegarde a pris la place de l'original).
S'il y a un problème, il est trop tard pour empêcher l'écrasement d'un base originale saine par une base sauvegardée corrompue.
Le fonctionnement n'est pas secure selon ce principe.

Merci de ne pas poster plusieurs messages à la suite, si vous devez ajouter un complément d'information, le bouton "Editer" à la droite du message permet d'y remédier.

En attendant une prochaine réponse, vous pouvez participer également en répondant à d'autres questions sur notre forum.

[jeanmi2403]

Bonjour,
Je suppose que ton fichier joint est la base avant sauvegarde, puisque chez moi il est fonctionnel.
Peux-tu nous rajouter dans ton post précédent le fichier APRÈS sauvegarde, pour qu'on puisse voir les différences et rechercher efficacement l'endroit où ça se passe...

le chemin UNC est mémorisé par la sauvegarde et il le remontera pour retrouver la table associée au formulaire.

Je ne crois pas beaucoup à ça... Surtout qu'il n'y a pas de chemin dans le message d'erreur que tu cites !!
Pour ce que j'en sais, le nom de la table est défini sans préfixe dans le formulaire.

Ajout : Je viens de parcourir les fichiers xml qui composent la base, je n'y ai trouvé aucun chemin dans le formulaire, juste le nom de la table. Content.xml.PNG Et je vois (dans le fichier meta.xml) que le fichier a été généré par LibreOffice/7.3.4.2 contrairement à ta signature...

Bonne journée,

[Bidouille]

capture.png

L'auteur ayant demandé la suppression de son compte, le fil est déclaré HS.

Désolé pour ceux qui ont consacré de leur temps pour rien.