LO Base DB mit Java lesen funktioniert nicht richtig

Ich habe LO Version 24.2.3.2 auf einem MacOS-Laptop laufen. Dort habe ich über LO Base eine DB angelegt, Tabellen erstellt etc. Alles sieht gut aus.
Jetzt greife ich mit einem Java-Programm über JDBC (Treiber: “org.hsqldb.jdbcDriver”) auf diese DB zu und finde leider meine dort erstellten Tabellen nicht. Ja, es ist die gleiche Datei !!
Wenn ich in Base das Statement “SELECT * FROM INFORMATION_SCHEMA.SYSTEM_TABLES” absetze, sehe ich meine Tabellen. Setze ich das Statement in dem Java-Programm ab, sehe ich sie nicht. Bei einer Tabelle, die ich über Java erzeugt habe, ist es umgekehrt. Greife ich z.B. mit DBVisualizer auf die DB zu, sehe ich nicht meine über Base erstellten Tabellen, sondern nur die per Java.
Als Dateinamen verwende ich den unter Registrierte Datenbanken in LO hinterlegten. Nach dem Zugriff über Java finde ich mehrere Dateien in dem Ordner der DB, die auch bestehen bleiben, beim Zugriff über Base nicht.
Wie kann erreichen, dass beide Zugriffe funktionieren.

Gruß
Andreas

Du hast eine interne Datenbank erstellt, vermutlich eine interne HSQLDB. Auf eine interne Datenbank kannst Du nur innerhalb von LibreOffice zugreifen.

Du wirst eine externe Datenbank benötigen, wenn Du von mehreren Positionen auf Deine Datenbank zugreifen willst. Wie so etwas mit der HSQLDB geht steht im Handbuch. Einfacher funktioniert das mit Firebird, weil dort nur die gerade ausgepackte Datenbankdatei kopiert und dann extern verknüpft werden muss.

Wenn Du einfach in LibreOffice in den ClassPath eine hsqldb.jar legst, dann läuftst Du Gefahr, interne Datenbankdateien nicht mehr öffnen zu können, weil die Versionen nicht mehr stimmen.

  1. Pack eine Kopie deines Datenbankdokuments mit eingebetteter HSQLDB in ein separates Verzeichnis.
  2. Lade eine Version <= 2.4.1 von hsqldb.org herunter. 2.4.1 war die letzte Version, die mit 1.8 kompatibel ist.
  3. Erstelle ein Unterverzeichnis “driver” und extrahiere hsql/lib/hsqldb.jar da rein.
  4. Installiere mein Python Macro von Apache OpenOffice Community Forum - [Python] Macro to extract and reconnect embedded HSQLDB - (View topic) (der dortige Anhang macht das automatisch).
  5. Öffne das Dokument aus 1. und starte das Makro über Extras>Macro>Ausführen>pyDBA>ExtractHSQL>Main

Wiederhole das Upgrade mit neueren Versionen, wenn Du magst. Dazu musst Du nur driver/hsqldb.jar gegen eine neuere Version ersetzen und das Makro nochmals aufrufen. Jede höhere Version upgradet die Datenbank irreversibel.

Vielen Dank für die schnellen Antworten.
Da ich die DB noch in der Entwicklung ist (als Ablösung einer Access-DB), habe ich mich entschlossen , den Weg über eine neue externe Firebird-DB zu gehen, wie RobertG vorgeschlagen hat. Das hat auch geklappt. Der Zugriff über LO klappt, das Erstellen von Tabellen etc auch.
Aber beim Zugriff auf die FB-DB wird ein User und ein Passwort verlangt. Da ich bei der Definition der DB nichts angegeben habe und ich auch in den System-DBs von LO nichts gefunden habe, stehe ich jetzt etwas auf dem Schlauch.
Hat jemand einen Tipp, mit was ich zugreifen kann? LO muss das ja irgendwie wissen, vermute ich.
Gruß
Andreas

PS: So super benutzerfreundlich ist das jetzt ja nicht gerade. Da ist noch Luft nach oben :wink:

Die Datenbankeinbindung ist nur eine winzige Ergänzung zu dieser Office Suite. Sie wird kaum weiterentwickelt und ist mit Access überhaupt nicht zu vergleichen. Firebird ist seit Jahren “experimental” und das vollkommen zurecht.

LO ist eine tolle Sache, die ich schon länger nutze,
Ich finde, das Base gegenüber den anderen Teilen etwas abfällt. Das finde ich schade. Im Normalfall komme ich damit ja auch gut zurecht. In dem speziellen Fall, in dem ich die Daten auch über Java verarbeiten möchte, ist es komplizierter, als ich das z.B. von Access kenne. Diese Art der Verarbeitung ist wahrscheinlich auch eher selten, aber sehr praktisch.

Am allerbesten funktioniert Base, wenn man weitgehend die Finger davon lässt. Paradox? Erstelle eine JDBC oder ODBC-Datenbank mit irgendwas anderem, und wenn diese Datenbank irgendwas mit LibreOffice zu tun haben soll, erstelle ein Base-Dokument.
Vermeide möglichst konsequent all die Assistenten, mit Ausnahme des Berichtsassistenten.
Schreibe komplexere SELECTs mit einem geeigneten Texteditor oder mit dem Tool, das die Datenbank erstellt hat.
Das manuelle Erstellen von Formularen mit dem Formular-Navigator und den Hilfsmitteln für grafische Elemente bringt auch ohne Makro-Code ganz passable Ergebnisse, jedenfalls sehr viel besser als alles, was Excel-Nutzer so zusammenwurschteln.
Die Berichte bieten so manches verborgenes Feature, das sich erst mit der Dokumentation von @RobertG erschließt. Mir genügt fast immer Calc und Calc’s Pivottabellen als Berichtsmedium.

Wirklich schlimm finde ich die Absturzhäufigkeit beim Bearbeiten von Berichten und Formularen. Beim Benutzen ist jedoch alles stabil. Man muss also möglichst oft speichern und Backups anlegen, sowie keinerlei eingebettete Datenbanken verwenden, außer für Pillepalle und Demos.

Habe die Default-Zugangsdaten gefunden.
Der Zugriff klappt jetzt.
Danke nochmal.

Wie hattest Du denn die externe Firebird-DB erstellt? Kommt da tatsächlich eine Passwortabfrage, wenn die über LibreOffice erstellt wird. Dann müsste ich das dringend ins Handbuch mit aufnehmen. für Firebird müsste das dann SYSDBA als Nutzer sein, aber das Passwort ?

Wenn Du eine interne Firebird Datenbank erstellst und daraus eine externe DB machst, dann kommt da keine weitere Abfrage.

Ich habe die DB über den Assistenten erstellt, Dabei wurde erst eine FB-DB neu erstellt und dann eine ODB, die die FB-DB als externe DB referenziert. In der Stautszeile steht auch ‘FireBird (extern)’ und der Dateiname. Hierbei wird kein User benötigt, auch die Nutzung über Base benötigt keinen.
Ich möchte ja auch über Java auf die DB zugreifen und dafür brauche ich den. Die Standardwerte habe ich gefunden und das klappt auch grundsätzlich. Leider ist die FDB in der Version 12.2 erstellt, die aktuellen Treiber unterstützen aber nur 13.1 und höher, sodass der Zugriff nicht klappt. Übrigens auch nicht über DBVisualizer. Der nutzt wahrscheinlich den gleichen Treiber für den Zugriff.
Gibt es eine Möglichkeit, in Base den verwendeten Treiber zu ersetzen, damit sowohl beim Anlegen der DB als auch beim Zugriff eine neuere Version benutzt wird?

Du kannst JDBC-Treiber konfigurieren unter Extras>Optionen>Erweitert, [Klassenpfad…], da wo auch die Java-Version festgelegt werden kann.
Bei HSQL hat das Eintragen einer neueren HSQLDB-Version die Auswirkung, dass man danach keine eingebetteten HSQLDB mehr benutzen kann. Ich weiß nicht, ob das für eingebettete Firebird auch so gilt.
Es gibt aber die Möglichkeit, den zu verwendenden JDBC Treiber individuell für das Datenbankdokument festzulegen. Dafür gibt es keine GUI, aber das folgende Basic-Snippet erledigt diesen Job. Kopiere das in den Basic editor und verändere die Konstanten. Das Makro versucht, aus Deinen Angaben eine gültige JDBC-URL zu verketten. Darüber hinaus trägt es den Pfad zum Treiber ein, die Java-Klasse, den Benutzernamen und ob beim Öffnen ein Passwort abgefragt werden muss oder ob das Passwort leer ist. Kommentiere die Aktionen aus, die Du nicht brauchst.

Sub Connect_JDBC_Backend()
REM This mini version of my FreeHSQLDB macro should be able to reconnect
REM a database document with any type of JDBC connection (HSQL, MySQL or other)
REM if you set up the right constants for a valid URL, a driver path and class name

REM oDoc = ThisDatabaseDocument ' this code is embedded in the odb
oDoc = ThisComponent ' this code is not embedded in the odb

REM-------- Database Location (URL) --------------------
REM protocol prefix refering to a set of files
REM Const cURL_Prefix = "jdbc:hsqldb:file:"
REM protocol prefix refering to a database server
Const cURL_Prefix = "jdbc:hsqldb:hsql:"

REM file path or server name with trailing slash
REM in case of cURL_Prefix = "jdbc:hsqldb:file:"

REM Const cURL_Path = "C:\path\hsqldb\DUMMY"
REM HSQL on Windows accepts strange URLs with slashes or with backslashes such as
REM Const cURL_Path = "C:\Users\UserName\HSQLDB\"
REM local files on a Linux sytem:
REM Const cURL_Path = "/var/hsql/database/"
REM in case of cURL_Prefix = "jdbc:hsqldb:hsql:" we specify a server name or IP address
REM Const cURL_Path = "//ServerName/"
Const cURL_Path = "//192.168/178.1/"

REM Either the database name is set up by a remote server if cURL_Prefix looks like "jdbc:hsqldb:hsql:
REM if cURL_Prefix looks like "jdbc:hsqldb:file:" the nae refers to a set of files starting with the same prefix
REM DatabaseName.properties DatabaseName.script DatabaseName.data etc.
Const cURL_DBName = "DUMMY" 'file name prefix or database name defined on server side

REM options that turned out to be useful with HSQL (see HSQL documentation)
Const cURL_Options = ";default_schema=true;shutdown=true;hsqldb.default_table_type=cached;get_column_name=false"

REM JDBC connections other than hsql may support other options
REM or none at all:
REM cURL_Options = ""

REM--------- Database Driver -------------------
REM use system notation for the local HSQL driver
Const cJarPath = "C:\path\hsqldb-2.4.1.jar"
REM the "ability" used by the JDBC driver when used with a client:
Const cClass = "org.hsqldb.jdbcDriver"

REM user name logging in at the JDBC database
Const cUser = "SA"

REM does the JDBC connection require any password?
Const cPwdRequired = False

REM if you insist in storing the password in the Base document (which is a security issue)
Const cPWD = ""

sURL = cURL_Prefix & cURL_Path & cURL_DBName & cURL_Options
sMsg = "URL: "& sURL & Chr(10) & _
		"JAR: "& cJarPath & Chr(10) & _
		"CLASS: "& cClass & Chr(10) & _
		"USER: "& cUser & Chr(10) & _
		"PWD: "& cPWD 
x = Msgbox(sMsg, 33)
if x = 2 then exit sub
on error resume next
   oDoc.CurrentController.ActiveConnection.close()
on error goto 0
oDataSource = oDoc.DataSource
oDataSource.URL = sURL
With oDataSource.Settings
   .JavaDriverClass = cClass
   .JavaDriverClassPath = ConvertToURL(cJarPath)
End With
oDataSource.User = cUser
oDataSource.IsPasswordRequired = cPWDReq
oDataSource.Password = cPwd
End Sub

Wahrscheinlich brauchst Du nur:

With oDataSource.Settings
   .JavaDriverClass = cClass
   .JavaDriverClassPath = ConvertToURL(cJarPath)
End With

Nein, der interne Treiber ist auf die Firebird-Version 3 ausgerichtet. Dateien, die mit einer neueren Version erstellt werden, weden mit der Fehlermeldung “Unsupported Disc structure” (oder so ähnlich) nicht geöffnet.
Da müsstest Du dann eine entsprechende Firebird-Datei aus dem Netz holen und die über JDBC anbinden.
Ich vermute aber, dass Dein ganzes Vorhaben eher nach einer Serverdatenbank schreit. Du willst ja schließlich noch von irgendwo anders her auf die Datenbank zugreifen. Und einen gleichzeitigen Zugriff von mehreren Positionen aus regeln zu können ist eben ein Server notwendig. Die einfachen externen Datenbanken dienen erst einmal nur dazu, eine höhere Datensicherheit zu erhalten. Interne Datenbanken werden ja beim Schließen von Base in die Base-Datei rein gepackt. Und wenn da etwas schief geht ist Datenverlust vorprogrammiert. Bei ausgelagerten Daten wird jeder Datensatz direkt in die Datenbank übernommen. Selbst beim Absturz von LO sind die Daten in der Datenbank drin.
Wie verbindest Du denn einfache Firebird-Datenbankdateien über JDBC mit anderen Programmen? Ich benötige dafür immer die Angabe eines Servers …

Der Eintrag der neuen Jaybird-Jar hat leider keine Änderung gebracht. Ich wüßte auch gar nicht, wie die Verbindung zum DB-Typ hergestellt wird.
Da ich jetzt schon mehr Zeit mit dem Drumherum verbracht habe als geplant, werde ich jetzt aufräumen und mit den ursprünglichen DBs weitermachen. Der Ansatz, den ich vorhatte, kann ich so zwar nicht umsetzen, aber ich kann mich beim Import/Export mit .csv-Dateien behelfen. Das ist zwar nicht so toll, wie ein direkter Zugriff, aber technisch (hoffe ich !!) schneller umzusetzen.
Ich werde die weitere Entwicklung von LO, speziell Base, beobachten. Vielleicht ergibt sich ja in naher oder ferner Zukunft eine Möglichkeit des Zugriffs, so wie ich ihn vorhatte.

Vielen Dank für die umfangreiche Unterstützung

Gruß
Andreas

Da gibt es nicht viel zu beobachten. Für Base werden nur noch grobe Regressionen gefixt oder kleine Nickeligkeiten. Base ist ein ungeliebtes Stiefkind.