[gnucash-de] Zurücksetzen des Bayes-Algorithmus

Peter Zimmerer pkzw at web.de
Do Feb 6 03:25:02 EST 2020


Hallo Christian,

vielen Dank für Deine ausführliche Antwort!
Meine Anworten auf Deine Fragen/Kommentare findest Du weiter unten.

Gruß,
Peter

Am 05.02.20 um 22:08 schrieb Christian Gruber:
> Hallo Peter,
> 
> auch wenn du bereits eine valide Lösung gefunden hast, die alten
> Mapping-Einträge in deiner Datenbank zu entfernen, habe ich mal noch ein
> paar Kommentare hinzugefügt.
> 
> Am 05.02.20 um 16:12 schrieb Peter Zimmerer:
>> Hallo zusammen,
>>
>> inzwischen habe ich die Reparatur wie unten vorgeschlagen auch
>> ausgeführt. Danach konnte ich die Import-Zuordnungen mit dem Editor
>> wieder bearbeiten.
>>
>> Gruß,
>> Peter
>>
>>
>> Am 03.02.20 um 18:03 schrieb Peter Zimmerer:
>>> Hallo zusammen,
>>>
>>> angeregt durch diese Diskussion habe ich auch mal bei mir versucht, den
>>> Editor für die Import-Zuordnungen aufzurufen. Leider führt das bei mir
>>> zum Crash von Gnucash mit folgender Fehlermeldung auf der Konsole:
>>>
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>    what():  basic_string::substr: __pos (which is 17) > this->size()
>>> (which is 16)
> Ich habe mal in den Code reingeschaut. Dieser Fehler tritt auf, wenn es
> Mapping-Einträge gibt, die kürzer als 16 Zeichen (Länge der Konto-GUID)
> sind. Dagegen ist der Code nicht abgesichert. Die Frage ist allerdings,
> wo kamen diese Einträge her?

Ich vermute, sie stammen noch aus der Zeit von Gnucash 2.X. Ich verwende
Gnucash unter Debian Linux. Letztes Jahr habe ich einen Upgrade von
Version 9 (Stretch) auf Version 10 (Buster) durchgeführt, der mit einem
Upgrade von Gnucash von Version 2.6 auf Version 3.4 einherging. Danach
konnte ich meine Gnucash-Datenbank nicht mehr öffnen. An den genauen
Fehler kann ich mich nicht mehr erinnern. Ich habe mich damals damit
beholfen, dass ich die Gnucash-Daten in Stretch in eine XML-Datei
gesichert und in diesem Format in Buster wieder eingelesen habe. Das hat
fehlerfrei funktioniert. Danach habe ich die Daten wieder in eine leere
Postgres-Datenbank gespeichert.

Ich habe bei mir sogar noch jeweils ein Backup der Datenbank von vor und
nach dem Upgrade gefunden. Vorher tauchten keine Import-Zuordnungen im
neuen Format auf, danach aber schon.

>>>
>>> Der Abbruch kommt aus der Funktion parse_bayes_imap_info (Quelldatei
>>> gnucash/libgnucash/engine/Account.cpp) und wird durch Einträge in den
>>> Mapping-Daten (Tabelle SLOTS) mit dem Wert NAME = 'import-map-bayes'
>>> verursacht.
>>>
>>> Daneben gibt es noch jede Menge Mapping-Einträge in der Tabelle SLOTS,
>>> die nicht dem Muster (regulärer Ausdruck)
>>> '^import-map-bayes/.*/[0-9a-f]{32}$' genügen. Ich vermute, das sind
>>> alles Mappings, die mit einer früheren Gnucash-Version angelegt wurden
>>> und die beim einem Upgrade nicht umgesetzt wurden. Sie zeigen mit Ihrer
>>> OBJ_GUID auch nicht auf eine gültige Konto-GUID, wie das der Fall ist,
>>> wenn ich heute eine neue Gnucash-Datei anlege, Kontoumsätze abfrage und
>>> zuordne und damit neue Mappings erzeuge.
> 
> Die Struktur der Mapping-Einträge wurde irgendwann mal gegenüber
> früheren Versionen geändert, sollte aber automatisch von GnuCash
> konvertiert werden, sobald während eines Imports mit einer neueren
> GnuCash-Version neue Mapping-Einträge angelegt werden.
> 
> Aufgrund des obigen Fehlers und den von dir gefundenen nicht
> regelkonformen Mapping-Einträgen vermute ich, dass bei dir beim
> Konvertieren der Mapping-Einträge etwas schief gelaufen ist. Der
> Konvertierungsvorgang kann ziemlich lange dauern. Ich habe kürzlich
> genau dazu eine Fehlermeldung analysiert (siehe Bug 797463
> <https://bugs.gnucash.org/show_bug.cgi?id=797463>). Könnte es sein, dass
> du GnuCash während des Konvertierungsvorgangs abgewürgt hast?

Vermutlich ist in dem oben beschriebenen Vorgehen bei der Konvertierung
was schiefgegangen oder sie wurde gar nicht ausgeführt. Vielleicht hilft
das DELETE-Statement ja jemandem, der in Zukunft das gleiche Problem
hat. Das Statement sollte auch unverändert mit Sqlite3 oder
MySQL/MariaDB funktionieren. Bei einer xml-Datei müsste man die Daten
erst im "Data Format" sqlite3 sichern, dann die alten Einträge mit
Sqlite3-Mitteln löschen, um sie dann im sqlite3-Format mit Gnucash
wieder zu öffnen und anschließend im xml-Format zu speichern.

Ist Dir eine Möglichkeit bekannt, die Konvertierung für die alten
Einträge noch nachzuholen?

Für mich wäre das allerdings nicht mehr relevant, da ich sie inzwischen
gelöscht habe. Aber vielleicht kann ja noch jemand anderes davon
profitieren.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20200206/f438aec7/attachment.sig>


Mehr Informationen über die Mailingliste gnucash-de