auch nicht in Fehlerlogdatei ~/.fakturama2/.metadata/.log (bei Linux / Mac OS) bzw. %USERPROFILE%.fakturama2.metadata.log? Laufen noch verwaiste Fakturama-Prozesse irgendwo? Ist die Datenbank erreichbar?

Rechner wurde neu gestartet.
Letzter Log Eintrag ist von gestern Abend.
Keine MySQL Datenbank

was passiert, wenn Du "Fakturama -clean" aufrufst? (im richtigen Programmpfad natürlich)

Ich habe nun länger gewartet bevor ich den Prozess abgeschossen habe und ein Log erhalten:

eclipse.buildId=unknown
java.version=1.8.0_151
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY com.sebulli.fakturama.common 4 0 2018-01-16 15:24:25.385
!MESSAGE couldn't create or update database!
!SESSION 2018-01-16 16:17:33.446 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_151
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY com.sebulli.fakturama.common 4 0 2018-01-16 16:22:38.809
!MESSAGE couldn't create or update database!

Ein Clean versuche ich gleich mal

Hm. Sieht aus, als ob was mit der Datenbank nicht stimmt. Kannst Du die anzeigen lassen? Ist die schreibgeschützt? Liegt die vielleicht auf einem entfernten Server?

Nein, die Datenbank liegt im Standard-Ordner lokal.

Sag nicht die ist jetzt im Eimer 🙁
Ich hatte noch keine Sicherung seit dem Update gemacht.

So hier das Ergebnis vom Clean-Start:

nicole@WS-Bueo:/usr/share/fakturama2$ ./Fakturama -clean
WARNING: Extender - Refreshing disabled - entities in bundle com.sebulli.fakturama.model may not be woven
[Server@6af5bbd0]: Initiating startup sequence...
[Server@6af5bbd0]: Server socket opened successfully in 3 ms.
[Server@6af5bbd0]: Database [index=0, id=0, db=file:/home/nicole/Fakturama2/Database/Database, alias=fakdbneu] opened successfully in 1002 ms.
[Server@6af5bbd0]: Startup sequence completed in 1013 ms.
[Server@6af5bbd0]: 2018-01-16 16:30:26.886 HSQLDB server 2.4.0 is online on port 9002
[Server@6af5bbd0]: To close normally, connect and execute SHUTDOWN SQL
[Server@6af5bbd0]: From command line, use [Ctrl]+[C] to abort abruptly
INFO 16.01.18 16:30: liquibase: Waiting for changelog lock....

...

liquibase.exception.LockException: Could not acquire change log lock. Currently locked by 2a02:8109:10c0:4298:e0bd:f37c:514d:ff1a%enp3s0 (2a02:8109:10c0:4298:e0bd:f37c:514d:ff1a%enp3s0) since 15.01.18 10:11
	at liquibase.lockservice.StandardLockService.waitForLock(StandardLockService.java:190)
	at liquibase.Liquibase.update(Liquibase.java:196)
	at liquibase.Liquibase.update(Liquibase.java:192)
	at com.sebulli.fakturama.dbservice.impl.DbUpdateService.updateDatabase(DbUpdateService.java:79)
	at com.sebulli.fakturama.LifecycleManager.checksBeforeStartup(LifecycleManager.java:157)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:305)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:233)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:107)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.lambda$0(E4Application.java:239)
	at java.util.Optional.ifPresent(Optional.java:159)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:235)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.start(E4Application.java:149)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1499)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1472)
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

Da klemmt irgendein Prozeß drauf. Bitte schau mal in der Prozeßliste (ps -aef | grep java) nach, ob dort irgendwelche Java-Prozesse rumhängen. Mit lsof kannst Du glaube ich auch sehen, welcher Prozeß welche Datei geöffnet hat.

nicole@WS-Bueo:/usr/share/fakturama2$ ps -aef | grep java
nicole 5256 4860 0 16:49 pts/18 00:00:00 grep --color=auto java

Tach auch,

ich habe hier den gleichen Fehler von gestern auf heute. Der Start von Fakturama -clean ergibt:

peter@peter-ThinkPad ~ $ /usr/share/fakturama2/Fakturama -clean
WARNING: Extender - Refreshing disabled - entities in bundle com.sebulli.fakturama.model may not be woven
[Server@1cde374]: Initiating startup sequence...
[Server@1cde374]: Server socket opened successfully in 11 ms.
[Server@1cde374]: Database [index=0, id=0, db=file:/home/peter/Nextcloud/nuw/Fakturama/Database/Database, alias=fakdbneu] opened successfully in 546 ms.
[Server@1cde374]: Startup sequence completed in 562 ms.
[Server@1cde374]: 2018-01-19 08:44:53.511 HSQLDB server 2.4.0 is online on port 9002
[Server@1cde374]: To close normally, connect and execute SHUTDOWN SQL
[Server@1cde374]: From command line, use [Ctrl]+[C] to abort abruptly
INFO 19.01.18, 08:44: liquibase: Waiting for changelog lock....
INFO 19.01.18, 08:45: liquibase: Waiting for changelog lock....
INFO 19.01.18, 08:45: liquibase: Waiting for changelog lock....
INFO 19.01.18, 08:45: liquibase: Waiting for changelog lock....

Moin,
erstmal ein großes Lob und vielen Dank für das wunderbar simple Programm.

Bisher hatte alles immer schön funktioniert, aber seit dem Update von 2.0.0 auf 2.0.0.1 tritt bei mir auch dieser Fehler auf. Nach dem Update konnte ich es einmal starten und arbeiten. Seitdem läßt sich die Datenbank nicht mehr öffnen. Es erscheint der Startbildschirm mit "checking database..." und dann passiert nix mehr.

Benenne ich den Ordner meiner Daten um und starte Fakturama, so dass das Arbeitsverzeichnis nicht da ist, öffnet das Programm mit einer leeren Datenbank. In dieser kann ich dann arbeiten und diese auch öfters wieder öffnen. Ich vermute daher, dass in der alten Datenbank irgendein alter Müll drin steht, der jetzt das öffnen verhindert. Gibt es eine Möglichkeit, den Inhalt der kompletten alten Datenbank zu exportieren und in eine neue zu importieren (also nicht nur Adressen, Produkte und Rechnungen, sondern auch Angebote und Mahnungen)?
Danke!
lutz

Das macht mich jetzt wirklich betroffen... Es scheint aber nur unter Linux ein Problem zu sein. Man kann die Daten über LibreOffice Base auslesen, User nicoletta hat da neulich was ausprobiert, das sah ziemlich vielversprechend aus. Ich habe das Problem bei mir bis jetzt nicht nachstellen können, auch unter meinen Linux-Umgebungen nicht. Habt ihr evtl. Produkte / Rechnungen oder Kontakte, bei denen längere Beschreibungstexte vorkommen?

Kannst Du nochmal auf die 2.0.0 zurückschwenken? Oder hast Du jetzt schon zu viele neue Daten in der Version 2.0.0.1 eingegeben?

Ich arbeite im Moment wieder mit der 2.0.0 und arbeite unter Windows10. In den Produkten habe ich schon längere Texte...

Lutz

Hallo zusammen,
ich hatte gerade die Vermutung, daß der Fehler hier evtl. an den großen Textfeldern (Beschreibungen usw.) liegt. Das hat sich aber nicht bestätigt. Ich habe in der v2.0.0.1 nur die zu kleinen Datenfelder größer gemacht, nicht umgekehrt (z. B. bei Zahlungsarten oder auch der Adresse).
Gerade eben habe ich das alles nochmal unter Debian getestet, mit vielen großen Datenfeldern usw. Ich bekomme den Fehler einfach nicht nachgestellt 🙁

Umgehungslösung (für die ganz Tapferen unter euch):

• Fakturama beenden
• Sicherung vom Arbeitsverzeichnis anlegen (klar)
• Datei Database/Database.script mit einem Editor (z. B. vi, nano o.ä.) öffnen
• die Zeile suchen, die mit "INSERT INTO DATABASECHANGELOGLOCK " beginnt
• diese Zeile ersetzen durch diese hier: INSERT INTO DATABASECHANGELOGLOCK VALUES(1,FALSE,NULL,NULL)

Das müßte dann vor jedem Start gemacht werden. Am besten man schreibt sich ein kleines Script mit 'nem sed-Befehl, der das jedesmal rauslöscht. Ist leider nicht optimal, aber bis mir eine bessere Lösung einfällt vermutlich die einzige Lösung.

Hintergrund: In dieser Tabelle merkt sich die Datenbank, ob gerade jemand an der Struktur der Datenbank herumwerkelt. Das wird bei jedem Start von Fakturama geprüft und läuft normalerweise durch. In eurem Fall ist es aber so, daß die Sperre nicht wieder gelöst wird und es deswegen jedesmal zu dem Problem kommt. Ich werde mich mal hinsetzen und herausfinden, wann genau in diese Tabelle geschrieben wird (das passiert über eine Dritt-Bibliothek, die ich mit verwende).