SUJET :

Bonjour,

L'augmentation des tailles de sauvegardes est logique: en effet, maintenant, une version PDF de toutes les documents officiels (facture, bilan, compte de résultat, appels de fonds, ....) sont sauvegardés.

Pour l'erreur, je ne l'ai toujours pas compris.
D'autant plus frustrant qu'elle ne se produit pas sur tout les environnements mais majoritairement sous Windows.

Sauf erreur, ce problème avec M$windows est triple: (1) impossibilité de supprimer les fichiers 'db.sqlite3', (2) impossibilité de vider ces databases de toutes leurs tables (généralement à partir de la deuxième restauration) et (3) un message d'erreur "utf-8" inadéquat.

Solutions
3) Message d'erreur "utf-8" inadéquat:Il semble bien que l'insertion de la ligne "proc_res.check_returncode()" après les commandes "proc_res = run(...)" éclaire alors le message:Voir fichier 'graphic_lib.py' ci-joint.

2) Impossibilité de vider la base de données:
La suppression de tables sql au moyen de 'DELETE FROM nom_de_la_table CASCADE;' génère 2 types d'erreur:

• OperationalError('near "CASCADE": syntax error',)

• IntegrityError('FOREIGN KEY constraint failed',)

La première est systématique mais n'est pas fatale tandis que la deuxième l'est pour certaines tables. Elle semble cependant corrigible en prévoyant une désactivation de 'FOREIGN KEY' spécifique à sqlite dans la fonction '_sql_to_clear'. La commande sql 'PRAGMA foreign_keys = OFF;' fait l'affaire.
Sous windows, ceci élimine l'erreur lors de restauration, objet du présent fil de discussion sur le forum Diacamma.
Voir fichier 'lucterios_admin.py' ci-joint.

1) Impossibilité de supprimer le fichier base de données à cause de l'erreur:Cette erreur est causée par la création d'un "handle" sur la database dans le processus principal de python à chaque fois que l'on sélectionne une instance dans la fenêtre "Lucterios". Ceci se produit aussi bien sous Linux que sous Windows Ces "handle" ne sont jamais libérés (!) avant la fermeture de python et, sous windows, il empêchent la suppression de la database dans le sous-processus 'restore'. Dans tous les cas, on peut donc se retrouver avec une quantité de "handle" simultanément ouverts sur le même fichier. Ce n'est certainement pas une bonne pratique. Reste encore à trouver un moyen pour clore proprement ces "handle". En attendant, sous windows, lorsqu'une instance est supprimée, les fichiers 'db.sqlite3' doivent être effacés à la main.

Puissent ces quelques suggestions permettre de soulager les Diacamiennes et Diacammiens toujours dépendants de M$windows.
Cordialement,
Louis

La solution c'est de créer une nouvelle instance avec un nouveau nom, la restauration est alors possible