Also die Groß-/Kleinschreibung der Tabellen kann hier nicht Fehler ursächlich sein. Schließlich wurde die Datenbank bei mir ja nicht von Windows nach Linux umgezogen, sondern hat bereits mit Version 2.1.3c auf genau dem gleichen Server unter MariaDB 10 funktioniert.

Habe daher mal eine neue leere Datenbank angelegt und die aktuelle 2.2.0 Beta vom 27.12. damit verbunden. Nach ca. 10min "checking database" kam auch hier wieder die Fehlermeldung "keine Verbindung zur Datenbank möglich". Nach Prüfung der DB stellte ich allerdings fest, dass sämtliche Tabellen korrekt angelegt wurden! Und zwar alle in Großschreibung exakt so wie es bereits in der bestehenden Datenbank der Fall war. Ebenso wurden in DATABASECHANGELOG alle 212 Einträge erstellt. Der einzige Unterschied ist, dass der Datentyp einiger Felder nun also von bit(1) auf tinyint(1) geändert wurde.

Da also sowohl die Prüfung der Datenbankverbindung als auch die Routine zur Ersteinrichtung der Datenbank demnach funktionieren, ist klar das besagtes Zugriffsproblem ein Bug in der Betaversion ist!

Das verstehe ich gerade nicht. Ich hab in einer Linux-VM bei mir das Installer-Paket installiert und mit MySQL verbunden. Damit hat Fakturama klaglos funktioniert. Ich weiß gerade nicht, wo ich hier ansetzen soll...

Hab gerade noch eine Aktualisierung hochgeladen und damit auch getestet. Die hat funktioniert.

Gibst Du in der Verbindungs-URL irgendwelche Schalter an?

Veröffentlicht von: @rhe_adm

↑

Gibst Du in der Verbindungs-URL irgendwelche Schalter an?

Ursprünglich hatte ich useMysqlMetadata und useCompression aktiv, was ich aber beides für den Test der Beta extra raus genommen habe.

Mir ist jetz noch aufgefallen, das die Verbindungsdaten nun mit jakarta und nicht mehr mit javax beginnen (ist wohl auf eine aktualisierung der verwendeten Bib zurück zu führen)!?

Irgendo muss es da ja einen Unterschied zwischen der Verbindung für Test und Ersteinrichtung der DB und der "regulären" Datenbankverbinung geben, da erstere ja Funktioniert und zweite zum Fehler führt.

Das mit dem Jakarta ist tatsächlich eine Folge der Aktualisierung. java.persistence ist seit einigen Jahren deprecated. Im Zuge des Updates wurde auch der Datenbank-Treiber aktualisiert. Der kommt inzwischen nicht mehr mit alten Datenbanken klar. Das scheint aber bei Dir auch nicht der Fall zu sein...

@rheydenr Obwohl er in eine leere DB ja sämtlich Tabellen usw. erzeugen kann, scheint es anhand des Fehlerlog ja "nur" an der anschließenden Prüfung bei Programmstart zu scheitern:

!SESSION 2025-01-02 16:29:28.420 -----------------------------------------------
eclipse.buildId=2.2.0.202412301012
java.version=17.0.2
java.vendor=Eclipse Adoptium
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Command-line arguments:  -os win32 -ws win32 -arch x86_64

!ENTRY com.sebulli.fakturama.common 4 0 2025-01-02 16:31:11.563
!MESSAGE c.s.f.LifecycleManager.checksBeforeStartup:158|couldn't create or update database!

In wie weit unterscheidet sich denn diese Prüfung von der Initialisierungsprüfung beim Eintragdialog der Datenbankverbindung? Da diese ja nach wie vor erfolgreich abgeschlossen werden kann (siehe: Screenshot)!

Wir haben gestern den Fehler gefunden (Groß-/Kleinschreibung bei den Data Query) und @rheydenr hat es auch bereits in einer Zwischenversion behoben, welche ich erfolgreich testen konnte. Mit der nächsten offiziellen Version sollte es also wieder funktionieren 👍