Hallo,
hilft Dir evtl. dieser Beitrag weiter?

... leider NEIN: Gleiche Fehlermeldung und hier das Terminal-Protokoll

Vielleicht sagt dieses Protokoll noch mehr aus ? Neben der neuen FAKTURAMA-Version ist auch noch die alte Version 1.6.9.x installiert und läuft (Gott sei Dank) weiterhin fehlerlos ...

Was hat eigentlich immer noch "sebulli" mit FAKTURAMA zu tun - kann das gegebenenfalls auch eine Fehlerquelle sein ?

nein, das "sebulli" ist einfach ein Relikt von früher, was ich noch nicht komplett weggeräumt habe.
Der Fehler sieht aus, als ob irgendwelche Einstellungen nicht gelesen werden konnten. Ich glaube, neulich hatte schon ein anderer Linux-Anwender dasselbe Problem. Ich hoffe mal nicht, daß es wieder am Linux liegt...
Welche Java-Version nutzt Du? Könntest Du die Installation evtl. wiederholen? Die Reorganisation ist übrigens nur dazu da, die Dokumente aus der alten in die neue Version reinzukopieren. Das geht natürlich auch manuell.

Das also ist die installierte JAVA-64-bit-Version:

java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)

Und was die nochmalige FAKTURAMA2-Installation betrifft: Diese habe ich bestimmt schon 10 x versucht, wobei zuletzt 4-5 x die diskutierte Fehlermeldung auftrat. Bei der Neuinstallation habe ich zuvor das Installationsverzeichnis /.fakturama2 und das Arbeitsverzeichnis /FAKTURAMA-2x geleert sowie die fehlerhafte Installation über die Synaptic-Paketverwaltung volltändig entfernt ...

Dann habe ich mit dem GDebi-Installationsprogramm das FAKTURAMA in der 64-bit-Version neu installiert, wobei dieses selber dann offensichtlich in /usr/share/fakturama2 untergebracht wird. Bei der Installation wurde das bisherige Arbeitsverzeichnis FAKTURAMA-1x angezeigt und von mir das neue FAKTURAMA-2x festgelegt. Nun erfolgte noch sichtbar die Datenübernahme incl. Konvertierung ...

Wenn das FAKTURAMA2 erstmalig gestartet wird, ist alles i.O.: Alle Einstellungen, Stammdaten und bisher unter FAKTURAMA1 erzeugten Dokumente sind vorhanden und können stichprobenweise geöffnet werden ...

Nach dem Beenden von FAKTURAMA2 und Neustarten kommt dann also die hier diskutierte Fehlermeldung ...

Hallo Jörg,
ich probier das selber nochmal auf einer Linux-Umgebung aus. Melde mich.

... ja, vielen Dank (tu):) - ich habe meine Systemumgebung deshalb genauer beschrieben, weil's eventuell ja unter UBUNTU, JAVA und FAKTURAMA in den 32-bit-Versionen schon laufen könnte, aber diese Umgebung habe ich eben nicht - es ist bei mir alles in den 64-bit-Versionen installiert und läuft ansonsten auch alles (bis auf FAKTURAMA2) problemlos ...

Hallo Jörg,
ich komme gerade bei dem problem nicht so richtig vorwärts. In dem Fehlerlog steht, daß es Probleme gab beim Einlesen der Einstellungen für die Formatierung der Kontaktdaten. Das sieht für mich danach aus, daß die Migration nicht richtig gelaufen ist, auch wenn das nicht ganz so offensichtlich ist. Kannst Du bitte mal prüfen, ob es mit der aktuellen Beta-Version besser ist?

... Leider NEIN - ich habe die Installation der BETA-Version genau so vorbereitet wie oben schon einmal beschrieben, dann installiert, nun erfolgte scheinbar korrekt die Konvertierung und nach dem Neustart erhielt ich wieder die Meldung ...

"Ein Fehler ist aufgetreten. Informationen hierzu enthält die Protokolldatei /home/joerg/.fakturama2/.metadata/.log."

Hier die vorangegangene Protokolldatei ...

Und hier die neue Protokolldatei ...

Die bisherigen Kontaktdaten beinhalteten sowohl Kunden (Debitoren) als auch Lieferanten (Kreditoren) mit den entsprechenden DATEV-gerechten Nummernkreisen:

- Kunden/Debitoren 6-stellig in der Kontenklasse 1
- Lieferanten/Kreditoren 6-stellig in der Kontenklasse 7

Die Nummern wurden bei der Neuanlage immer manuell vergeben und nicht in laufender Reihenfolge. Die Nummervergabe erfolgte nach einem bestimmten Schlüssel:

1. Stelle = Debitor oder Kreditor "1" oder "7"
2.-3. Stelle = alphabetische Einordnung "11"=A, "12"=B, "13"=C usw.
4.-6. Stelle = lfd. Nummer innerhalb des gleichen Buchstabens

Beispiel-1: "112005" steht für einen Kunden/Debitoren mit einem Namen, dessen Anfangsbuchstabe mit "B" beginnt, und er wurde unter diesem Buchstaben als 5. Kunde angelegt.

Beispiel-2: "730012" steht für einen Lieferanten/Kreditoren mit einem Firmennamen, der mit "T" beginnt und darunter als 12. angelegt wurde.

Warum wurde das so gemacht ? Die Aktenablage für Kunden und Lieferanten erfolgt bei mir ebenfalls alphabetisch, d.h. es gibt Kunden- und Lieferanten-Ordner mit entsprechenden Trennblättern oder Halb- bzw. Ösenheftern; die Suche nach älteren Vorgängen geht damit blitzschnell ...

Und da FAKTURAMA bisher kein entsprechendes System der Nummernvergabe unterstützte, habe ich eben diese Nummern manuell festgelegt. Zwischen den Kunden- und Lieferanten-Nummern gibt's damit immer mal größere Lücken. Vielleicht kommt hiermit die Konvertierung nicht zurecht ... ?

Nein, die Fehler deuten auf ein anderes Problem hin, was eher technischer Art ist. Irgendwas ist mit dem Installationsverzeichnis oder dem .fakturama2-Verzeichnis quer. Jedenfalls werden da Klassen gesucht, die eigentlich da sein müßten, die aber trotzdem nicht gefunden werden. Ich kann nur versuchen, das anhand Deiner Anleitung nochmal durchzuspielen.

Ich habe von dieser Programmierung keine Ahnung (letztmalig in den 1980-er Jahren in PROLOG programmiert, später "nur" noch die Konzepte und Projekte gemacht): Was bedeutet hier "Klassen" ... ?

Eigenartig ist allerdings, dass man nach dem ersten Programmstart, also direkt nach Abschluss der Datenkonvertierung, im FAKTURAMA2 durchschauen konnte, wie's aussieht und ob die Daten vollständig sind. Und hier stimmten u.a. sowohl die Dokumente als auch die Kontakte (Debitoren) ... (tu) und erst nach einem Neustart (2. Programmaufruf) ging nichts mehr ... (td)

Hallo Jörg,
die Info mit den Klassen ist nicht so wichtig.
Falls Du noch nicht mit dieser Version arbeitest (was ich mal annehme, weil's ja nicht geht 🙂 ), lösch bitte mal das Verzeichnis ~/.fakturama2 sowie das neu angelegte Arbeitsverzeichnis (kannst Du auch umbenennen, falls Du es aufheben willst) und installiere die Beta-Version nochmal neu (auch mit Datenübernahme aus der 1.x-Version).

Danke Ralf - das probier' ich in den nächsten Tagen aus und melde mich wieder ...

Beste Grüße - Jörg

Hallo Ralf,

ich konnte erst jetzt an dem leidigen "Thema" weiterarbeiten, jedoch wiederum erfolglos, d.h. eine nochmalige Installation auch der Beta-Version unter einem nunmehr sogar neuen Programmverzeichnis (vorher /usr/share/fakturama2, jetzt direkt unter /home/joerg/Fakturama2-Beta) und einem neuen Arbeitsverzeichnis (/home/joerg/FAKTURAMA-2) mit Datenkonvertierung war zwar problem- und fehlerlos möglich (alle Stamm- und Arbeitsdaten waren vorhanden), aber nach einem nochmaligen Programmstart gab es wieder die bekannte Fehlermeldung:

"Ein Fehler ist aufgetreten. Informationen hierzu enthält die Protokolldatei
/home/joerg/.fakturama2/.metadata/.log."

Den Inhalt der aktuellen Log-Datei kannst Du hier einsehen ...

Hallo Ralf,

ich habe gestern mal, weil mir die Zeit z.V. stand, mein UBUNTU 16.04.x LTS auf 18.04.x LTS geupgradet, wie's mir seit kurzem vom Aktualisierungs-System immer wieder angeboten wurde. Das hat auch alles ganz gut geklappt und ich dachte mir dann, eventuell noch mal FAKTURAMA2 unter diesem System zu installieren. Es ist dabei folgendes passiert:

(1) Die ersten 2-3 Installationen verliefen problemlos, nur wurden von der FAKTURAMA1 absolut keine Daten übernommen und konvertiert, d.h. es gab absolut keine Stamm- und Arbeitsdaten. Über eine Datenbank für eine Mehrplatz-Nutzung verfüge ich übrigens nicht. Aus diesem Grund hatte ich also die Installation mehrmals mit gleichem Ergebnis vorgenommen. Das FAKTURAMA2 ließ sich auch mehrmals ohne Fehlermeldungen starten. Die "Installation" war jedoch nichts Anderes als das Etablieren des kompletten FAKTURAMA2-Programm-Ordners in mein Home-Verzeichnis und von dort aus wurde FAKTURAMA2 gestartet.

(2) Ich habe dann mal die DEB-Datei (Fakturama_linux_x64_2.0.2.0.deb) installiert, so dass sich das Programm dann unter /usr/share/fakturama2 wiederfindet und von der UBUNTU-Dash (ich nutze unter UBUNTU 18.04.x LTS weiterhin UNITY) aus gestartet werden kann - FAKTURAMA1 ist dort auch noch zu finden. Ich startete dann also von der Dash aus das FAKTURAMA2 ...

(3) ... und hier wurde dann wieder eine Datenübernahme mit Konvertierung durchgeführt. Die übernommenen Daten sahen auf den ersten Blick alle i.O. aus und ich startete mal die Reorganisation. Danach war dann FAKTURAMA2 komplett neu zu starten und es kam wieder zur bekannten Fehlermeldung, d.h. ins Programm kam man schon nicht mehr.

Fazit:

a) Eine Installation ist problemlos möglich und eine Nutzung eventuell auch, wenn man seine Daten neu anlegt.

b) Bei der Datenübernahme incl. Konvertierung aus FAKTURAMA1 muss etwas passieren, was einen problemlosen Neustart verhindert - unmittelbar nach der Datenübernahme und -konvertierung könnte man eventuell noch problemlos arbeiten, nach einem Neustart aber nicht mehr.

Woran könnte das nun liegen ? Wird FAKTURAMA2 nach der Datenübernahme incl. Konvertierung nicht korrekt geschlossen (z.B. EOF-Fehler) ? Müssen die Stamm- und Arbeitsdaten einer bestimmten Struktur entsprechen ? Bei mir sind z.B. die Dokumenten-Nummern 10-stellig (Angebote, Rechnungen usw.), einige Dokumente nicht ausgedruckt, die Kontakt-Nummer 6-stellig und nicht laufend durchnummeriert, sondern manuell nach einem bestimmten System vergeben ...

Besteht die Möglichkeit, die FAKTURAMA1-Daten zu sichern und unter FAKTURAMA2 zurückzusichern, wonach dann erst eine Konvertierung erfolgt ... ?

Notfalls könnte ich Dir einmal vertraulich meinen relativ kleinen Datenbestand zur Fehlersuche und für Tests z.V. stellen ...

Bis dahin erst einmal beste Grüße - Jörg