Sauvegarde/Restauration '\utf-8' codec decode byte

Installation & configuration MS-Windows
1

Bonjour,

J’ai installé la nouvelle version de Diacamma, version 2.4.4.19112711.

Lors de sauvegarde ou bien de restauration d’un projet/instance, j’obtiens le message d’erreur Python suivant :
« ‘\utf-8’ codec can’t decode byte 0xe9 position 999: invalid continuation byte »

J’ai remplacé la valeur de position par 999 dans le message d’erreur car cette valeur varie a priori à chaque opération de sauvegarde ou de restauration.

Par exemple :
‘\utf-8’ codec can’t decode byte 0xe9 position 402: invalid continuation byte
‘\utf-8’ codec can’t decode byte 0xe9 position 858: invalid continuation byte
‘\utf-8’ codec can’t decode byte 0xe9 position 144: invalid continuation byte

Cordialement

2

Bonjour,

Problème noté mais sans solution.
Cela doit venir d’un souci de configuration que je n’arrive pas à reproduire.
Une correction sera apportée quand le problème sera mieux compris.

3

Bonjour,

J’ai le même soucis.(Voir pièce jointe) Cependant, la sauvegarde et la restauration effectuent correctement

4

Bonjour,

Il pourrait être intéressant, dans le message d’erreur (‘\utf-8’ codec can’t decode byte 0xe9 position 999: invalid continuation byte), de rajouter le libellé de la chaîne de caractères incriminée.

Cordialement

5

Bonjour,

Faute de mieux, une solution pour contourner le problème de restauration (par exemple impossibilité de restauration après mise à jour de Diacamma) avec message d’erreur contenant des mots tels que Unicode utf-8 byte, par exemple :
" UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xe9 in position 400: invalid continuation byte "
est de supprimer avec Diacamma l’instance considérée, de quitter Diacamma et de supprimer (ou renommer en .OLD) aussi le répertoire du nom de l’instance sur le File System (a priori sous C:\Lucterios2) puis relancer Diacamma pour créer une nouvelle instance nommée du même nom et enfin restaurer la sauvegarde.
Rem. : si la nouvelle version de Diacamma n’a pas été correctement installée avec la mise à jour, il est possible de de désinstaller Diacamma et de le réinstaller, … mais c’est plus long.

Testé avec la version Diacamma Syndic 2.4.11 du 24/06/2020, sous Windows 10.

6

Bonjour,
j’ai le même problème.
Les sauvegardes qui faisaient auparavant 588Ko font dorénavant 12684 Ko…
Et il est impossible de restaurer ces grosses sauvegardes, j’ai la même erreur 0xe9 in position 398…
J’ai choisi donc de sauvegarder le fichier db.sqlite3 en le mettant dans un autre dossier et en le numérotant V1 v2 etc…
Mais c’est pas très classe.

La solution à ce problème a-t-elle été trouvée?

Merci de vos réponses!

François

7

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.

8

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:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 398: invalid continuation byte

Il semble bien que l’insertion de la ligne “proc_res.check_returncode()” après les commandes “proc_res = run(…)” éclaire alors le message:

subprocess.CalledProcessError: Command '['c:\\lucterios2\\Python\\python.exe', '-m', 'lucterios.install.lucterios_admin', 'restore', '-n', 'syndic2', '-f', 'C:/Users/Myself/savugarde3.lbk']' returned non-zero exit status 1.

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. :slight_smile:
Voir fichier ‘lucterios_admin.py’ ci-joint.

1) Impossibilité de supprimer le fichier base de données à cause de l’erreur:

[WinError 32] Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus: 'C:\\lucterios2\\syndic2\\db.sqlite3'

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. :slight_smile:
Cordialement,
Louis

9

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