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

[Christian Gruber]

Am 06.02.20 um 09:25 schrieb Peter Zimmerer:
> 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?

Da ich noch nicht lange genug mit GnuCash arbeite und daher selbst keine
Konvertierung durchführen musste, kann ich nur das wiedergeben, was ich
bisher über diesen Konvertierungsvorgang gelernt habe.

Der Konvertierungsvorgang sollte mit jeder neueren GnuCash Version
möglich sein. D.h. man sollte auch mit einer aktuellen Version 3.8 noch
eine alte Datenbank, die z.B. mit der Version 2.6 gespeichert wurde,
konvertieren können. Dass es bei dir damals Probleme beim Öffnen der
Datenbank gab, kann an Bugs in der Version 3.4 gelegen haben, die
eventuell mittlerweile behoben sind.

Die Konvertierung findet nicht direkt beim Öffnen der älteren Datenbank
statt, sondern erst wenn Änderungen an den Mapping-Einträgen vorgenommen
werden, d.h. wenn ein Import von Transaktionen durchgeführt wird (und in
den Einstellungen unter "Onlinebanking" "Bayes-Algorithmus verwenden"
aktiviert ist).

In deinem konkreten Fall könntest du versuchen, die alte Datenbank mit
einer aktuellen GnuCash Version noch einmal zu öffnen und anschließend
irgendeinen Import von mindestens einer Transaktion durchführen (kann
auch z.B. ein CSV-Import sein). Danach hast du aber trotzdem noch das
Problem, die Mapping-Einträge aus dieser alten Datenbank in eine andere
aktuellere Datenbank zu übernehmen. An dieser Stelle kann ich nicht
weiterhelfen. Ich kann aber sagen, dass ein Kopieren der Einträge ohne
Modifikationen ausreichen sollte. Jeder Eintrag besteht aus den vier
Angaben, die auch im "Import-Zuordnungen Editor" angezeigt werden, d.h.
dem Herkunftskonto, einer "Zuordnungs-Zeichenfolge", dem Zuordnungskonto
und der Häufigkeit. Die beiden Konten werden über GUIDs identifiziert,
welche über alle GnuCash-Versionen eindeutig und unverändert sind.

>
> 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.
>