Hallo,

mit der Version 0.2.10 habe ich folgendes Problem: Ich hatte ein Konto erfolgreich eingerichtet und auch Regeln für die Zuordnung der Umsätze definiert, alles prima.

Dann habe ich testweise eine weitere Bankverbindung eingerichtet. Deren Umsätze wurden dann auch importiert und dank der Regeln automatisch zugeordnet (zum großen Teil jedenfalls).

Da es ja nur ein Test war, habe ich das Konto dann wieder entfernt.

Nun stehen überall in meinen Kategorien aber noch Buchungen, die zu dem gelöschten Konto gehören, und sämtliche Summen stimmen dementsprechend natürlich auch nicht mehr.

Was kann ich tun? Alles wegwerfen und neu anfangen? Oder gibt es noch eine andere Möglichkeit?

Danke & Gruß — Stefan

Nachtrag: in der SQLite-Datenbank (accounts.sqlite) stehen nach dem Löschen jetzt tatsächlich nur die Umsätze, die zum "richtigen" Konto gehören, übrigens unverschlüsselt.
Die CoreData-Ablage PecuniaData.sparseimage ist verschlüsselt.

Noch ein Nachtrag: Jetzt verstehe ich, wie die Verschlüsselung der Daten läuft — die CoreData-Ablage wird in ein verschlüsseltes Sparse Image verlegt. Die andere Datei war die ältere, die ohne manuelles Zutun dort liegenbleibt. Vielleicht wäre es für die Sicherheit vorteilhaft, wenn man zusätzlich zu dem dezenten Hinweis gleich anbietet, die Datei (dauerhaft) zu löschen oder im Finder anzuzeigen, damit der Benutzer sie z.B. verschieben kann.

Jedenfalls habe ich nun nochmal nachgesehen, denn das verschlüsselte Sparse Image kann ich ja selber aktivieren. Und da sehe ich nun, dass alle Datensätze noch drin sind, d.h. auch die des gelöschten Kontos.

Frage daher: Kann ich per SQLite-Kommandozeile einfach die "falschen" Buchungen löschen?

Also zunächst einmal finde ich den Titel unangebracht. Er weckt den Anschein als hinterließe das Löschen eines Kontos ein komplettes Datenchaos. Das ist aber nicht richtig. In der Regel möchte man die Umsätze ja behalten, wenn man ein Konto löscht (z.B. weil man die Bank gewechselt hat) da einem ansonsten die komplette Historie verlorengeht.
Allerdings habe ich - zugegebenermaßen - an so einen Fall wie deinen nicht gedacht. Ich werde also in Zukunft eine Abfrage einbauen, ob die Umsätze mit Kategoriezuordnung mitgelöscht werden sollen.
Theoretisch könnte man die Umsätze mit Datenbankmitteln löschen. Das ist allerdings nicht so einfach und ich würde dir dringend abraten es zu versuchen.
Wenn du noch nicht so lange mit Pecunia arbeitest kannst du die Daten ja neu aufsetzen. Wenn doch könnte ich dir anbieten eine Supportversion zu erstellen, die die "falschen" Umsätze löscht.

Hallo Frank!



Du hast Recht — ich bitte um Entschuldigung. Im Nachhinein kommt mir der Titel auch "reißerischer" vor als er beabsichtigt war.
Es war halt einfach die Situation, dass offenbar alle Umsatzzahlen in den Kategorien unwiederbringlich strubbelig sind; deshalb habe ich ja auch hier um Hilfe gefragt.
Möglicherweise wäre es auch sinnvoll, ein aufgehobenes Konto nicht ganz zu "löschen", sondern zu "deaktivieren" — dann wäre es z.B. ausgegraut in der Liste, wenn ein Zeitraum selektiert ist, in dem es nicht existiert (nur mal so ins Unreine gesprochen).



Das wäre vermutlich eine sinnvolle Erweiterung, die auch nicht allzuviel Mühe bei der Implementierung bereiten sollte. Die oben genannte Alternative mit dem Deaktivieren wäre dagegen deutlich aufwendiger.



SQL wäre grundsätzlich nicht das Problem. Ich hatte bisher nur noch nicht die Gelegenheit, die CoreData-/DB-Struktur zu "reverse engineeren", um das passende Delete-Statement zusammenzustricken.
Im übrigen kann man ja vorher ein Backup der DB anlegen oder Time Machine nutzen, falls die Aktion in die Hose geht.



Wie gesagt – eine Info über das passende SQL-Delete wäre vermutlich für Dich mit dem geringsten Aufwand verbunden.

Noch etwas: Ist es angedacht, zwischen mehreren Datenbanken (Benutzern) umzuschalten? Theoretisch könnte man das ja vor Programmstart durch Verschieben der Datenbankdatei erreichen, nur die anderen Einstellungen würden dann bestehen bleiben, etwa die Regeln. Oder?

Danke & Gruß — Stefan

Das Delete-Statement ist nicht das Problem. Das Problem ist eher: wie erkenne ich die richtigen Umsätze?
In der Tabelle Z_2STATEMENTS wird der Link zwischen Konto/Kategorie und Umsatz gespeichert. Das ist prinzipiell eine 1:n-Beziehung, d.h. ein Umsatz kann zu mehreren Kategorien gehören. Wenn ein Umsatz einer Kategorie zugeordnet ist, ist es eine 1:2-Beziehung, d.h. der Umsatz ist einmal dem Konto und einmal der Kategorie zugeordnet.
Es gibt eigentlich nur einen Weg die betroffenen Umsätze zu finden: wenn der Umsatz nur eine 1:1-Beziehung hat und das Ziel eine Kategorie (nicht ein Bankkonto) ist (ZISBANKACC=0), dann gehört er zu einem gelöschten Bankkonto und kann ebenfalls gelöscht werden.
Keine Ahnung ob man das mit einem SQL-Statement ermitteln kann...

Hmm... Ich habe jetzt testweise alle Umsätze gelöscht, die als lokales Konto das gelöschte haben — es scheint jetzt wieder alles zu stimmen.
("delete from zbankstatement where zlocalaccount is $geloeschteskonto")

Ist das realistisch? Oder laufe ich dann bei nächster Gelegenheit in eine Falle? Ich muss zugeben, die CoreData-Datenmodell habe ich nicht 100% verstanden; Tabelle ztransfer (Entity Transfer) ist bspw. leer.

Naja, jetzt hast du halt in der Tabelle Z_2STATEMENTS Zombie-Einträge rumstehen. Ich hab keine Ahnung wie gut oder schlecht CoreData damit zurechtkommt. Du kannst es ja mal versuchen, heb dir deine Datensicherung gut auf.

Also, bis jetzt funktioniert es tadellos.

Woran könnte ich denn einen Zombie-Eintrag erkennen?

Den erkennst du daran, dass er auf nicht existierende Einträge in den anderen Tabellen verweist, also z.B. auf einen nicht existierenden Eintrag in der ZCATEGORY.
Aber wenn alles soweit funktioniert scheint CoreData damit ja zurechtzukommen.