In LibreOffice gibt es das Programmmodul «Base». Dies stellt eine grafische Benutzeroberfläche für Datenbanken zur Verfügung. Daneben existiert, in LibreOffice eingebunden, die interne Datenbank «HSQLDB» sowie die interne Datenbank «Firebird». Diese internen Versionen der Datenbanken können nur als Datenbanken von einem Nutzer betrieben werden. Die gesamten Daten sind in der *.odb-Datei mit abgespeichert und diese Datei ist nur für einen Benutzer nicht schreibgeschützt zu öffnen.

Die Erstellung einer internen Datenbank erfolgt direkt über den Eingangsbildschirm von LO mit einem Klick auf den Button Datenbank oder über Datei → Neu → Datenbank. Der Datenbank - Assistent startet mit dem folgenden Bildschirm:

Das Optionsfeld «Neue Datenbank erstellen» ist für eine neue interne Datenbank angewählt. Standardmäßig ist dies die eingebettete HSQLDB. Für die seit LO 4.2 existierende interne Firebird-Datenbank müssen zur Zeit (LO 24.1) noch die experimentellen Funktionen (Extras → Optionen → LibreOffice → Erweitert → Optionale Funktionen) aktiviert werden. Ist eine eingebettete interne Firebird-Datenbank erst einmal erstellt, so ist die Aktivierung der experimentellen Funktionen nicht mehr erforderlich.

Die weiteren Optionen dienen dazu, eine bestehende Datei zu öffnen oder eine Verbindung zu einer externen Datenbank wie z.B. einem Adressbuch, einer MySQL-Datenbank o.ä. aufzubauen.

Eine in LibreOffice angemeldete Datenbank kann von den anderen Programmteilen von LibreOffice als Datenquelle genutzt werden (z. B. Serienbrief). Diese Anmeldung kann aber auch zu einem späteren Zeitraum erfolgen. Deshalb ist an dieser Stelle erst einmal das Optionsfeld Nein, die Datenbank soll nicht angemeldet werden, ausgewählt.

• Tipp 

Base-Datenbankdateien werden auch für die Erstellung von Serienbriefen benötigt. Dort sind sie häufig nur für die Verbindung von Datenquelle zu einer Writer-Datei zuständig. Solche Dateien können nur angemeldet genutzt werden. Damit sie nicht irgendwann verschoben oder ihr Sinn völlig vergessen und die Datei gelöscht wird sollten sie an einem Ort unter gespeichert werden, der zu den Benutzereinstellungen von LibreOffice gehört. Über Extras → Optionen → LibreOffice → Pfade kann der Pfad zu den Benutzereinstellungen gefunden werden. In diesem Pfad befindet sich auch ein Verzeichnis database. Hier liegt unter anderem die Datenbankdatei «biblio.odb», die standardmäßig mit LibreOffice ausgeliefert wird. Eine dort abgespeicherte Datenbankdatei ist vor versehentlicher Löschung recht gut geschützt.

Bei den Markierfeldern ist lediglich «Die Datenbank zum Bearbeiten öffnen» markiert. Assistenten zur Erstellung von Tabellen, Abfragen usw. werden in diesem Handbuch nicht genutzt. Ihre Funktion ist lediglich für den einfachen Einstieg in die Materie geeignet.

Die Datenbankdatei wird fertiggestellt, indem direkt nach einem Namen und einem Speicherort gefragt wird. An der entsprechenden Stelle wird dann die *.odb-Datei erzeugt, die zur Aufnahme von Daten aus der internen Datenbank, zur Speicherung von Abfragen, Formularen und Berichten gedacht ist.

Im Gegensatz zu den anderen Programmteilen von LibreOffice wird also die Datei abgespeichert, bevor der Nutzer überhaupt irgendwelche für ihn sichtbare Eingaben getätigt hat.

Die interne Firebird Datenbank könnte in Zukunft die interne HSQLDB ersetzen. Zur Vereinfachung des Wechsels wird an einem Migrationstool gearbeitet. Dieses Tool bietet die Migration von HSQLDB zu Firebird an, wenn über Extras → Optionen → LibreOffice → Erweitert → Optionale (instabile) Einstellungen die experimentellen Funktionen aktiviert werden:

Die HSQLDB ist auch für LibreOffice 24.2 die Standarddatenbank für jeden Nutzer; die Firebird-Datenbank hat mit LO 5.3 ein Update auf die aktuelle Firebird-Version 3.0 vollzogen, ist aber bisher eingeschränkt zu empfehlen. Die Datenbank-Beispiele beziehen sich weiterhin überwiegend auf die HSQLDB, sind aber so angepasst, dass die meisten Funktionen direkt auf Firebird übertragbar sind. Gegebenenfalls werden Alternativen in Firebird direkt aufgezeigt.

• Hinweis 

Die Nutzung von Firebird ist mit der Version LO 6.4.3 wieder in den experimentellen Status zurückversetzt worden. Die Einbindung in die grafische Benutzeroberfläche wird allerdings beständig verbessert.

• Vorsicht 

Mit den experimentellen Funktionen erscheint bei jedem Öffnen einer internen HSQLDB-Datenbank (über den Zugriff auf den Tabellencontainer) ab LO 6.1 der folgende Dialog:

Hier ist äußerste Vorsicht geboten! Später drücken und dann erst einmal eine Sicherungskopie der Datenbankdatei machen. Auf keinen Fall einfach bestätigen! Die Migration funktioniert nicht einwandfrei, kann dies auch vermutlich nie.

1. 1.Sicherheitskopie der HSQLDB-Datenbankdatei anfertigen. 

2. 2.Funktionen nach der im Anhang des Handbuches unter «Migation HSQLDB → Firebird» stehenden Liste so weit wie möglich anpassen. 

3. 3.Ansichten, die nicht direkt umgestellt werden können, vom SQL-Code her kopieren und als Abfragen abspeichern. 

4. 4.Tabellennamen und Spaltennamen dürfen in Firebird nur maximal 31 Zeichen lang sein. Gegebenenfalls also anpassen. 

5. 5.Reine Texttabellen (eingebundene *.csv-Tabelle etc.) sind unter Firebird nicht möglich, müssen also anderweitig ersetzt werden. Prinzipiell gibt es auch bei Firebird eine Möglichkeit, bestimmte Textdateien (nicht: *.csv-Dateien) einzubinden. Diese Funktion ist aber aus Sicherheitsgründen standardmäßig nicht eingeschaltet. 

Alle externen Datenbanken müssen zuerst einmal existieren. Angenommen es soll der Zugriff auf die Datenbank einer eigenen Homepage erfolgen. Dort muss zuerst einmal die Datenbank selbst mit einem Namen und Zugangsdaten gegründet worden sein, bevor externe Programme darauf zugreifen können.

Existiert nun diese externe Datenbank, so kann sie, je nach vorhandener Treibersoftware, zur Erstellung von Tabellen und anschließender Dateneingabe und -abfrage genutzt werden.

Über Datei → Neu → Datenbank wird der Datenbankassistent geöffnet und die Verbindung zu einer bestehenden Datenbank hergestellt. Die Liste der hier aufgeführten Treiber, die mit Datenbanken verbinden, variiert etwas je nach Betriebssystem und Benutzeroberfläche. Immer dabei sind aber

• •dBase 

• •JDBC 

• •MySQL/MariaDB 

• •ODBC 

• •Oracle JDBC 

• •PostgreSQL 

• •Firebirddatei 

• •Tabellendokument 

• •Text 

• •sowie verschiedene Adressbücher 

Je nach gewählter Datenbank variieren nun die Verbindungseinstellungen. Diese können auch gegebenenfalls später noch korrigiert werden, wenn erst einmal die *.odb-Datei erstellt worden ist.

Bei manchen Datenbanktypen können keine neuen Daten eingegeben werden. Sie sind deshalb nur zum Suchen von Daten geeignet (z.B. Tabellendokument, Adressbücher). Die Beschreibungen in den folgenden Kapiteln beziehen sich ausschließlich auf die Verwendung von LibreOffice Base mit der internen Datenbank HSQLDB. Die meisten Ausführungen lassen sich auf Datenbanken wie MySQL, PostgreSQL etc. übertragen und entsprechend anwenden.

Hier soll nur kurz an ein paar Beispielen vorgestellt werden, wie der Kontakt zu anderen externen Datenbanken hergestellt wird.

• Hinweis 

In Abhängigkeit vom benutzten Treiber ist es möglich, gleichzeitig auf mehrere Datenbanken des jeweiligen Servers zuzugreifen. Wird z.B. in MySQL/MariaDB mit der direkten Verbindung ein Kontakt zu einer Datenbank hergestellt, so werden in Base gleichzeitig alle anderen Datenbanken auf dem Server angezeigt, bei denen der angegebene Nutzer Leserecht hat. Es ist also problemlos möglich, Daten von einer Datenbank zu einer anderen zu kopieren, zusammenhängende Abfragen durchzuführen usw.

• Hinweis 

ODBC-Verbindungen werden in Linux direkt über die Anweisungen in den Dateien «odbcinst.ini» und «odbc.ini» erstellt. Für Windows existiert hier eine GUI, die bei der Erstellung helfen soll. Dort scheint es dann aber vor zu kommen, dass für LibreOffice nicht nur die existierenden eingetragenen Datenquellen angeboten werden, sondern auch leere Datenquellen.
Auf die Erstellung von ODBC-Verbindungen unter Windows kann hier nicht weiter Bezug genommen werden, da zum einen mehrere Treiber existieren, die GUI zu viele Einstellungsmöglichkeiten zulässt (die einer GUI als Allroundwerkzeug geschuldet sind) und außerdem mir als Autor das Betriebssystem nicht zur Verfügung steht.

MySQL-Datenbanken oder auch MariaDB-Datenbanken können auf drei verschiedene Weisen mit Base verbunden werden. Die einfachste und schnellste Art ist die direkte Verbindung mit dem MySQL-Connector. Daneben steht noch die Verbindung über JDBC und ODBC zur Verfügung.

• Hinweis 

In MySQL und MariaDB ist es möglich, Daten in Tabellen ohne ein Primärschlüsselfeld einzugeben und zu ändern. Die GUI von Base zeigt diese Tabellen zwar an, bietet aber keine Eingabe- bzw. Änderungsmöglichkeit.
Wer Tabellen ohne Primärschlüssel verwenden möchte, kann stattdessen über Extras → SQL, oder innerhalb von Formularen über Makros, die Tabellen mit Daten versorgen.

Nachdem MySQL bzw. MariaDB installiert ist, sollten nacheinander die folgenden Schritte vollzogen werden:

1. 1.Der Administrationsuser in MySQL heißt «root». Für Linuxnutzer ist hier wichtig, dass es sich dabei nicht um den Administrator des Linuxsystems handelt. Diesem Nutzer wird direkt nach der Installation erst einmal ein Passwort zugewiesen. Dies kann je nach System auch schon vorher bei der Installation erfolgt sein. In der Konsole wird nach der Anmeldung als «sudo»
   mysqladmin -u root password 'Passwort'
   eingeben. Anschließend wird mit
   mysql -u root -p
   der Kontakt zu MySQL bzw. MariaDB hergestellt. Hier muss jetzt das Passwort eingegeben werden.
   Es erscheint die Eingabeaufforderung
   mysql>
   Alle folgenden Eingaben werden jetzt auf dieser mysql-Konsole erstellt. Die Passwörter können sich unterscheiden, je nachdem, ob die Anmeldung von dem momentanen Rechner («localhost») oder von einem anderen Rechner zum MySQL-Serverrechner («host») erfolgt.
   SET PASSWORD FOR root@localhost=PASSWORD('Passwort');
   SET PASSWORD FOR root@host=PASSWORD('Passwort');
   Windows-Nutzer geben statt der zweiten Zeile
   SET PASSWORD FOR root@'%'=PASSWORD('Passwort');
   ein. 

2. 2.Als Sicherheitsmaßnahme werden alle eventuell bestehenden anonymen Nutzer gelöscht.
   DELETE FROM mysql.user WHERE User='';
   DELETE FROM mysql.db WHERE User='';
   FLUSH PRIVILEGES; 

3. 3.Eine Datenbank mit dem Namen «libretest» wird erstellt.
   CREATE DATABASE libretest; 

4. 4.Alle Rechte an der Datenbank «libretest» werden dem Nutzer «lotest» übergeben, der sich durch das Passwort «libre» ausweisen soll.
   GRANT ALL ON libretest.* TO lotest IDENTIFIED BY 'libre'; 

Damit ist die Datenbank vorhanden, mit der die folgenden Verbindungen aufgebaut werden.

Für eine Verbindung über ODBC muss natürlich erst einmal die entsprechende ODBC-Software installiert sein. Details dazu werden hier nicht weiter beschrieben.

Nach Installation der entsprechenden Software kann es passieren, dass LO den Dienst verweigert, weil es die libodbc.so.1 nicht findet. Hier existiert in den meisten Systemen inzwischen die lib­odbc.so.2 . Auf diese Datei muss ein entsprechender Verweis mit dem Namen libodbc.so.1 in dem gleichen Verzeichnis abgespeichert werden.

In den für das System notwendigen Dateien odbcinst.ini und odbc.ini müssen Einträge ähnlich den folgenden existieren:

1. 001 [MySQL] 

2. 002 Description = ODBC Driver for MySQL 

3. 003 Driver = /usr/lib64/libmyodbc5.so 

1. 001 [MySQL-test] 

2. 002 Description = MySQL database test 

3. 003 Driver = MySQL 

4. 004 Server = localhost 

5. 005 Database = libretest 

6. 006 Port = 3306 

7. 007 Socket = 

8. 008 Option = 3 

9. 009 Charset = UTF8 

Diese beiden Dateien liegen bei einem Linux-System im Verzeichnis /etc/unixODBC. Ohne den Eintrag zur Art des verwendeten Zeichensatzes kommt es bei Umlauten zu Problemen, auch wenn die Einstellungen in MySQL/MariaDB und Base übereinstimmen.

Der Zugriff auf eine existierende MySQL-Datenbank erfolgt mit der direkten Verbindung in den folgenden Schritten:

Über «Neue Datenbank erstellen» ist nur die Erstellung einer Datenbank im internen HSQLDB-Format möglich. Die Zusammenarbeit mit anderen Datenbanken kann nur erfolgen, wenn die Datenbank selbst bereits existiert. Dazu muss also Verbindung zu einer bestehenden Datenbank herstellen gewählt werden.

Hier wird aus den, teilweise betriebssystemspezifischen, Datenbanken die MySQL-Variante ausgewählt.

Die direkte Verbindung ist diejenige, die von der Geschwindigkeit her für die MariaDB am besten gewählt werden sollte. Allerdings hat sie auch ein paar kleine Bugs, die gegebenenfalls besonders berücksichtigt werden müssen. So ist es z. B. dringend erforderlich, in Formularen bei Textfeldern die maximale Länge einzustellen, weil sonst die Eingabe einfach auf den bisher maximal eingegebenen Wert gekürzt wird.

Der Datenbankname muss bekannt sein. Befindet sich der Server auf dem gleichen Rechner wie die Benutzeroberfläche, unter der die Datenbank erstellt wird, so kann als Server «localhost» gewählt werden. Ansonsten kann die IP-Adresse (z.B. 192.168.0.1) oder auch je nach Netzwerkstruktur der Rechnername oder gar eine Internetadresse angegeben werden. Es ist also ohne weiteres möglich, mit Base auf die Datenbank zuzugreifen, die vielleicht auf der eigenen Homepage bei irgendeinem Provider liegt.

Alternativ zu den Serverangaben kann (unter Linux) auch direkt der Socket eingegeben werden. Der Standardsocket kann dafür aus der Datei /etc/my.cnf ausgelesen werden.

Auch der Socket benötigt einen laufenden MariaDB/MySQL-Server. Es ist also nicht möglich, ohne gestarteten Server auf die Datenbanken in dem Server zuzugreifen. Auch die Nutzung einer anderen Instanz als der des systemweiten Servers ist nicht möglich.

Bei der Arbeit mit Base über das Internet sollte sich der Nutzer allerdings darüber bewusst sein, wie seine Verbindung zu der Datenbank gestaltet ist. Gibt es eine verschlüsselte Verbindung? Wie erfolgt die Passwortübertragung?

Jede über das Netz erreichbare Datenbank sollte mit einem Benutzernamen und einem Kennwort geschützt sein. Hier wird direkt getestet, ob die Verbindung klappt. Wichtig ist natürlich, dass der entsprechende Benutzer in MySQL bzw. der MariaDB entsprechend für den benannten Server eingerichtet wurde.

Dieses Fenster erscheint anschließend bei jedem Start der Datenbankdatei, wenn das erste Mal auf die MySQL-Datenbank zugegriffen wird.

Der Verbindungstest startet die Authentifizierung mit vorgegebenem Benutzernamen. Nach Passworteingabe erfolgt die Meldung, ob die Verbindung erfolgreich hergestellt werden kann.
Läuft z.B. MySQL zur Zeit nicht, so kommt natürlich an dieser Stelle eine Fehlermeldung.

Auch hier wird die Datenbank nicht angemeldet, da sie nur zu ersten Tests aufgebaut wurde. Eine Anmeldung ist erst notwendig, wenn andere Programme wie z.B. der Writer für einen Serienbrief auf die Daten zugreifen sollen.

Der Assistent beendet die Verbindungserstellung mit dem Abspeichern der gewünschten Datenbankverbindung. In dieser *.odb-Datei liegen jetzt lediglich diese Verbindungsinformationen, die bei jedem Datenbankstart ausgelesen werden, so dass auf die Tabellen der MySQL-Datenbank zugegriffen werden kann.

Ansicht der geöffneten Datenbankdatei mit Tabellenübersicht und in der Fußzeile der Benennung des verwendeten Treibers «MySQL (nativ)», des Datenbanknamens «libretest», des Nutzers der Datenbank «lotest» und des Servers, auf dem die Datenbank läuft, nämlich «localhost».

Über Fertigstellen wird die Base-Datei erstellt und die Ansicht auf die Tabellen der MySQL-Datenbank geöffnet. Die Tabellen der Datenbank werden unter dem Namen der Datenbank selbst aufgeführt.

Beim manchen Treibern wird nur die Datenbank «libretest» angezeigt, für die auch die Verbindung bestimmt war. Andere Treiber von LO bieten auch andere MySQL- bzw. MariaDB-Datenbanken auf dem gleichen Server zur Auswahl, für die der Nutzer mindestens eine Leseberechtigung hat.

Auch mit den Treibern für nur eine Datenbank ist aber ein Zugriff auf die anderen Tabellen z.B. für Abfragen möglich, sofern natürlich der angegebene Datenbanknutzer, im obigen Fall also «lotest», mit seinem Passwort auf die Daten zugreifen kann. Im Gegensatz zu den bisherigen nativen LO-Treibern ist hier allerdings kein schreibender Zugriff auf andere Datenbanken des gleichen MySQL-Datenbankservers möglich.

Im Unterschied zu der internen Datenbank von Base taucht bei Abfragen entsprechend in MySQL für die Definition der Tabelle immer auch der Datenbankname auf, hier z.B.

1. 001 ... FROM "libretest"."Klasse" AS "Klasse" ... 

Hier ist es also auf jeden Fall notwendig, der Kombination aus Datenbankname und Tabellenname mit dem Zusatz «AS» einen alternativen Alias-Namen zuzuweisen. Genaueres siehe dazu in dem Kapitel «Verwendung eines Alias in Abfragen».

• Hinweis 

Durch diese Aliaszuweisung werden Abfragen, die aus mehreren Tabellen bestehen, nicht mehr editierbar, auch wenn alle anderen Bedingungen erfüllt sind. Dann muss in der durch die GUI erstellten Abfrage im SQL-Code "libretest"."Klasse" AS (also der Hinweis auf den Datenbanknamen) entfernt werden. Dann gelingt auch eine bearbeitbare Abfrage über mehrere Tabellen.

Tabellen können in der Datenbank erstellt und gelöscht werden. Automatisch hoch zählende Zahlenfelder («Autowert») funktionieren und lassen sich auch bei der Tabellenerstellung auswählen. Sie starten bei MySQL mit dem Wert '1'.

Die ersten Schritte zur ODBC-Verbindung sind gleich denen zur direkten Verbindung. Wird beim zweiten Schritt dann die ODBC-Verbindung für MySQL gewählt, dann erscheint das folgende Fenster des Datenbank-Assistenten:

Die ODBC Datenquelle hat nicht unbedingt den gleichen Namen wie die Datenbank in MySQL selbst. Hier muss der Name eingetragen werden, der auch in der Datei «odbc.ini» steht. Die einfachste Möglichkeit besteht hier darin, über den Button Durchsuchen den Namen aus der «odbc.ini» direkt auszulesen.

Beim Test erscheint der Name aus der «odbc.ini». Auch wenn hier wieder nur mit einer Datenbank verknüpft wird, können andere Tabellen des MySQL-Servers sehr wohl gelesen werden.

Schritt 4 und 5 laufen wieder identisch zur Direktverbindung ab.

Auch bei der JDBC-Verbindung sind die ersten Schritte gleich, hier unterscheidet sich wieder nur Schritt 3 von den anderen Schritten des Assistenten:

Der Assistent fragt hier die gleichen Informationen ab wie bei der direkten Verbindung. Der Datenbankname ist der, der auch in MySQL selbst verwandt wird.

Über «Klasse testen» wird überprüft, ob das Archiv mysql-connector-java.jar über Java erreichbar ist. Entweder muss dieses Archiv im Pfad der ausgewählten Java-Version liegen oder direkt in LibreOffice eingebunden werden.

Alle weiteren Schritte sind wieder identisch zu denen der vorherigen Verbindungen. Die Verbindungen zu anderen Datenbanken des gleichen MySQL-Datenbankservers funktionieren ebenfalls nur lesend.

• Hinweis 

Bei Verwendung des MariaDB-Treibers muss die JDBC-Treiberklasse mit «org.mariadb.jdbc.Driver» angegeben werden.
Für MySQL wird in neueren Version nach der Version 5 die JDBC-Treiberklasse «com.mysql.cj.jdbc.Driver» benötigt.

• Hinweis 

Die verschiedenen Verbindungen zu MySQL/MariaDB wurden oben jeweils mit der Beziehung zum örtlichen Server «localhost» getestet. Sie funktionieren grundsätzlich auch als Verbindungen zu Datenbanken eines Providers im Internet. Allerdings ist hier zu beachten, dass der Server des Providers für Kontakte von außerhalb ein wait_timeout eingestellt haben kann. Nach einer entsprechenden Zeit ohne Datenaustausch wird dann die Verbindung unterbrochen. Je nach Einstellung des Servers kann es erlaubt sein, diese Zeitspanne zu beeinflussen.

1. 001 SHOW SESSION VARIABLES LIKE 'wait_timeout'; 

2. 002 SET SESSION wait_timeout=600; 

Zuerst wird die Einstellung des Servers über Extras → SQL ermittelt. Die Standardeinstellung eines Servers ohne entsprechende Konfiguration liegt bei 28800 Sekunden, also 8 Stunden. Ist dies nicht der Fall, dann kann für die Session eine Zeitspanne (hier: 600 Sekunden oder 10 Minuten) eingegeben werden. Sobald in dieser Zeit wieder eine Abfrage läuft wird die Zeitspanne bis zur nächsten Unterbrechung wieder auf 10 Minuten gesetzt.

Ist die Einstellung der Zeitspanne nicht möglich, so hilft das folgende Makro:

1. 001 GLOBAL boStop AS BOOLEAN 

    

2. 001 SUB Reconnect 

3. 002    DIM oDatasource AS OBJECT 

4. 003    DIM oConnection AS OBJECT 

5. 004    DIM oSQL_Command AS OBJECT 

6. 005    boStop = false 

7. 006    DO 

8. 007       WAIT 30000 'Zeitangabe in Millisekunden 

9. 008       oDatasource = thisDatabaseDocument.CurrentController 

10. 009       oConnection = oDatasource.ActiveConnection() 

11. 010       oSQL_Command = oConnection.createStatement() 

12. 011       oSQL_Command.executeQuery("SELECT NOW()") 

13. 012    LOOP WHILE boStop = false 

14. 013 END SUB 

     

15. 001 SUB StopConnect 

16. 002    boStop = true 

17. 003 END SUB 

Zuerst wird eine globale Variable erstellt, damit die Schleife in der Prozedur Reconnect auch unterbrochen werden kann. In der Prozedur wird alle 30 Sekunden eine einfache Abfrage gestellt, die nicht weiter ausgewertet wird. So bleibt der Kontakt zum Server erhalten, wenn wait_timeout größer als 30 Sekunden ist und die Netzverbindung einwandfrei funktioniert. Die Einstellung der Zeitspanne ist hier dem Test überlassen. Mit der Prozedur StopConnect schließlich lässt sich die Prozedur Reconnect wieder unterbrechen.

Wird dieses Makro mit dem Öffnen der Datenbank aufgerufen, so muss natürlich innerhalb der ersten 30 Sekunden auf jeden Fall der erste Kontakt zur Datenbank mit Passworteingabe hergestellt werden.

Bei der JDBC-Verbindung lässt sich hier mit dem Parameter autoReconnect=true eine Verbindung direkt wieder herstellen. Die erste Unterbrechung findet dann trotzdem statt, bei einem zweiten Kontaktversuch ist die Verbindung aber wieder da.

Bei der direkten Verbindung funktioniert das nicht. Stattdessen muss die Datenbankdatei geschlossen und wieder geöffnet werden um erneut einen Kontakt herzustellen. Die Verbindungsdaten wie Nutzername und Passwort müssen aber nicht neu eingegeben werden, solange LibreOffice selbst nicht beendet wird..

Auf dem Datenbankserver können neben Tabellen und Ansichten auch Prozeduren gespeichert werden. Werden diese Prozeduren direkt auf der Konsole von MySQL aufgerufen, so können dort zum Teil Tabellenansichten ähnlich einer sonst in Base sichtbaren Ansicht («View») abgerufen werden. In Base sind diese Tabellenansichten nicht sichtbar. Ein Aufruf der Prozeduren unter Extras → SQL ist problemlos möglich, nur erfolgt leider keine Ausgabe der anzuzeigenden Inhalte. Um Inhalte der gespeicherten Prozeduren («Stored Procedures») zu sehen kann der folgende Weg beschritten werden:

• •Statt einer Prozedur wie
  CREATE PROCEDURE AlleNamen()
  BEGIN
          SELECT * FROM `libretest`.`Namen`;
  END
  wird das Ergebnis der Prozedur in eine temporäre Tabelle geschrieben:
  CREATE PROCEDURE AlleNamen()
  BEGIN
          DROP TEMPORARY TABLE IF EXISTS `libretest`.`TempNamen`;
          CREATE TEMPORARY TABLE `libretest`.`TempNamen` AS SELECT *
                  FROM `libretest`.`Namen`;
  END 

• •Anschließend wird unter Extras → SQL die Prozedur aufgerufen:
  CALL AlleNamen(); 

• •Jetzt befinden sich die Ausgabedaten in einer temporären Tabelle, die nur für den aktuellen Nutzer von MySQL sichtbar ist. Die Ausgabedaten werden in einer Abfrage über
  SELECT * FROM `libretest`.`TempNamen`
  sichtbar. 

Die Abfrage funktioniert nur dann einwandfrei, bei der Erstellung der Prozedur auch die Datenbank (in diesem Fall "libretest") mit angegeben wird. Wie das Ganze etwas besser automatisiert ablaufen kann ist im Kapitel «MySQL-Datenbank mit Makros ansprechen» beschrieben.

Für die PostgreSQL-Datenbank gibt es wie bei MySQL/MariaDB einen direkten Treiber von LO, der von vornherein mit installiert wird. Damit der Kontakt auch sicher passt, zuerst aber eine kurze Anleitung zu den ersten Schritten nach der Installation von PostgreSQL.

Die folgenden Schritte sind nach einer Installation über den Paketmanager in OpenSUSE erforderlich. Sie ähneln vermutlich denen unter anderen Betriebssystemen.

1. 1.Dem Nutzer «postgres» muss zuerst ein Passwort zugewiesen werden. Das kann mit dem Administrationstool des Betriebssystems erfolgen. 

2. 2.Der PostgreSQL-Server muss vom Administrator gestartet werden, z. B. service postgresql start oder rcpostgresql start. 

3. 3.Der Nutzer «postgres» muss sich mit
   su postgres
   auf der Konsole anmelden. 

4. 4.Ein einfacher Datenbanknutzer, hier «lotest», sollte mit Passwortzugang erstellt werden:
   createuser -P lotest 

5. 5.Damit der Datenbanknutzer anschließend auch auf die zu gründende Datenbank zugreifen kann, muss in der Datei /var/lib/pgsql/data/pg_hba.conf ein Eintrag geändert werden. In dieser Datei werden u.a. die Methoden zur Identifizierung der Nutzer auf verschiedenen Ebenen festgelegt. Die Methode, mit der LO-Base kommunizieren kann, ist die Methode «password» oder «md5», nicht, wie voreingestellt, die Methode «ident». 

6. 6.Der Systemnutzer «postgres» meldet sich über «psql» an:
   psql -d template1 -U postgres 

7. 7.Der Systemnutzer «postgres» erstellt die Datenbank «libretest»:
   CREATE DATABASE libretest; 

Der Nutzer «lotest» hat nicht die gleichen Rechte wie der Nutzer «postgres». Meldet sich der Nutzer «postgres» direkt beim System über su postgres an, so kann er beispielsweise zusätzliche Schemas für eine Datenbank erstellen:

1. 1.Der Systemnutzer «postgres» meldet sich über «psql» an:
   psql -d libretest -U postgres 

2. 2.Der Systemnutzer «postgres» erstellt das Schema «reports»:
   CREATE SCHEMA reports; 

3. 3.Der Systemnutzer «postgres» setzt den Nutzer «lotest» als Eigentümer für das Schema ein:
   ALTER SCHEMA reports OWNER TO lotest; 

Der Nutzer «lotest» kann jetzt auf dieses Schema zugreifen. Allerdings erscheint es nicht direkt in der Übersicht. Wird aber über die GUI in Base eine Tabelle erstellt, so kann diese in dem Schema «reports» gespeichert werden und anschließend wird das Schema auch in der Liste der Tabellen angezeigt.

Im Assistenten wird der Eintrag «postgres» ausgewählt. Die Verbindungseinstellung geschieht über die Angabe des Datenbanknamens («dbname») und des Hostes. Unter bestimmten Umständen ist es erforderlich, statt der einfachen Angabe eines Hostes den kompletten Host einschließlich des vollständigen Domainnamens anzugeben. Gegebenenfalls muss auch noch separat «port=5432» hinzugefügt werden. Dies sollte aber nur notwendig sein, wenn ein anderer als der Standardport gewählt wird.

Die Benutzer-Authentifizierung sieht genauso aus wie die unter MySQL. Neben «dbname» und «host» können hier noch «port», «connect_timeout» und andere Einträge erstellt werden.

Wird die Datenbank das erste Mal geöffnet, so erscheinen für den User erst einmal eine Unmenge an Tabellen aus dem Bereich «information_schema». Diese Tabellen sind ebenso wie die im Bereich «pg_catalog» für den normalen Nutzer nur lesbar, nicht schreibbar. Diese verschiedenen Bereiche bezeichnet PostgreSQL als «Schema». Der Nutzer legt neue Tabellen im Schema «public» an.

Der Dialog «Speichern unter» zeigt hier verschiedene Schema von PostgreSQL auf. Tatsächlich speicherbar ist allerdings nur in dem Schema «public», solange keine weitreichenderen Nutzerrechte für den entsprechenden Anmeldenamen vergeben wurden.

• Hinweis 

Werden Tabellen z.B. aus der internen HSQLDB nach PostgreSQL kopiert, so schlägt der Importassistent den einfachen Tabellennamen aus der HSQLDB, z.B. «Tabelle1», vor. Der Import mit diesem Namen schlägt allerdings fehl. Stattdessen muss vor den Namen die Schemabezeichnung ergänzt werden: aus «Tabelle1» wird «public.Tabelle1».

In der Tabellenübersicht von PostgreSQL erscheinen die unterschiedlichen Schemata. Im Schema «public» ist die abgespeicherte Tabelle «Name» zu sehen.

• Hinweis 

Die Ansicht auf andere Verzeichnisse als das Verzeichnis "public" kann auch über Extras → Tabellenfilter eingeschränkt werden.

Neben dem direkten Treiber ist natürlich auch die Verbindung über JDBC oder ODBC möglich.

Während der direkte Treiber z. B. keine Erstellung von Ansichten in der GUI erlaubt oder immer mit der Tabellenansicht in dem Tabellenverzeichnis "information_schema" beginnt, lässt die JDBC-Verbindung die Erstellung von Ansichten zu und zeigt standardmäßig nur das Tabellenverzeichnis mit dem Schemanamen "public" oder andere selbst erstellte Schemata an. Nur in diesem Bereich werden schließlich neue Tabellen des Nutzers erstellt. Auch ist der JDBC-Treiber der einzige, der in der GUI automatisch hoch schreibende Primärschlüsselfelder in der GUI erzeugt.

Hier die direkte Eingabe der Datenbankverbindung für einen lokalen Server zur Datenbank «libretest».

Der JDBC-Treiber wiederum hat Probleme bei der Verwendung von Abfragen mit Aliasbezeichnungen für Tabellen. Wenn ein Primärschlüssel automatisch hoch geschrieben werden soll, so wird dies bei Abfragen mit Aliasbezeichnungen nicht korrekt ausgelesen. Dies führt dann zu angeblichen 0-Werten als Primärschlüssel und Datenverlust, wenn nach dem ersten Abspeichern Daten in so einem Datensatz geändert werden.

Aus diesem Grund hier auch noch funktionierende Standardeinstellungen für die ODBC-Verbindung von PostgreSQL. Leider ist auch diese Verbindung nicht frei von Mängeln. So lassen sich hier über die GUI keine Ansichten erstellen, solange noch keine Ansicht existiert. Dem kann aber abgeholfen werden, indem eine erste Dummyansicht über Extras → SQL erstellt wird:

1. 004 CREATE VIEW "public"."vtest" AS SELECT * FROM "public"."Tabellenname" 

Wird danach die Datenbankdatei abgespeichert und wieder neu geladen, so können Ansichten auch über die GUI mit der ODBC-Verbindung erstellt werden.

In den für das System notwendigen Dateien odbcinst.ini und odbc.ini müssen Einträge ähnlich den folgenden existieren:

1. 001 [PSQL] 

2. 002 Description=PostgreSQL 

3. 003 Driver64=/usr/lib64/psqlodbcw.so 

4. 004 UsageCount=1 

1. 001 [PostgreSQL-libretest] 

2. 002 Description = PostgreSQL connection to libretest 

3. 003 Driver = PSQL 

4. 004 Database = libretest 

5. 005 Servername = localhost 

6. 006 ReadOnly = No 

7. 007 RowVersioning = No 

8. 008 ShowSystemTables = No 

9. 009 ConnSettings = SET SEARCH_PATH TO libretest; 

Mit diesen Einstellungen ist eine Verbindung unter Linux möglich. Serielle Felder, die in PostgreSQL der Ersatz für Autoincrement-Werte sind, wurden anstandslos ausgelesen. Auch die Nutzung von Aliasbezeichnungen in Abfragen beeinflussten nicht, wie bei dem JDBC-Treiber, die korrekte Rückgabe der Werte nach Neueingaben.

PostgreSQL hat die Eigenart, dass innerhalb einer Datenbank unterschiedliche Schemata für unterschiedliche Zwecke angelegt werden können. Häufig wird ein anderer Schemaname als «public» beim Import von Daten aus anderen Datenbanken gewählt. Der Eintrag für die ConnSettings bewirkt, dass alle Schemata aus der Datenbank «libretest» angezeigt werden. Soll nur ein Schema angezeigt werden, so wird der Name dieses Schemas, das sich in der Datenbank befindet, eingetragen.

PostgreSQL unterstützt nicht direkt Autoincrement-Werte. Stattdessen kann ein Feld, das automatisch hochzählende Werte generieren soll, als Feld des Typs SERIAL definiert werden.

1. 001 CREATE TABLE "public"."Test" ( 

2. 002 "ID" SERIAL PRIMARY KEY 

3. 003 ); 

Auch über

1. 001 CREATE TABLE "public"."Test" ( 

2. 002 ID INTEGER PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY 

3. 003 ); 

kann mit neueren Versionen von PostgreSQL ein AutoWert-Feld erzeugt werden.

Hier wird ein automatisch hoch zählendes Feld "ID" als Primärschlüssel definiert. Die entsprechende Eingabe unter Extras → SQL erzeugt die Tabelle "Test". Wird anschließend über Ansicht → Tabellen aktualisieren die Anzeige der Tabelle ermöglicht, so kann die Tabelle in dem GUI-Editor anschließend weiter bearbeitet werden (rechte Maustaste auf der Tabelle → Bearbeiten).

Über den JDBC-Treiber ist es möglich, direkt Felder des Typs SERIAL zu erstellen. Unter Bearbeiten → Datenbank → Erweiterte Einstellungen → Generierte Werte darf dazu aber kein Eintrag erfolgen. Wird dort SERIAL eingetragen, so wird die Abspeicherung der Tabelle mit einer Fehlermeldung unterbrochen. Der dort eingeblendete Begriff für die Erstellung des automatisch hoch zählenden Feldes muss dann entfernt werden, damit das Abspeichern gelingt.

Bei dBase handelt es sich um ein Datenbankformat, dass alle Daten in einem beliebigen Verzeichnis in separaten Tabellen bereitstellt. Verknüpfungen zwischen den Tabellen müssen über die Programmstruktur erledigt werden. dBase hat keine Möglichkeit, intern zu verhindern, dass z.B. in der Medien-Datenbank ein Medium gelöscht wird, der Verweis darauf aber weiterhin in der Tabelle zum Entleihen von Medien erhalten bleibt.

Die Verbindung wird zu einem Verzeichnis hergestellt. Alle *.dbf-Dateien, die sich in diesem Verzeichnis befinden, werden anschließend angezeigt und können über Formulare miteinander verbunden werden.

Tabellen in dBase haben kein unverwechselbares Feld für jeden Datensatz («Primärschlüssel»). Sie können also vom Prinzip her so beschrieben werden wie Tabellenblätter in Calc.

Tabellen können in Base neu erstellt werden. Sie werden dann einfach als neue Dateien in das angegebene Verzeichnis geschrieben.

Für neue Tabellen stehen deutlich weniger Feldtypen zur Verfügung als für die interne HSQLDB. Dabei sind noch einige Bezeichnungen der folgenden Abbildung als Verdoppelungen anzusehen.

dBase bietet sich besonders an, wenn es um Weitergabe und vielfältige Verarbeitungsmöglichkeit von Daten geht. Schließlich können auch Tabellenkalkulationen dBase-Tabellen direkt einlesen.

Base übernimmt einfach die Codierung, die dem Betriebssystem entspricht. Alte dBase-Dateien weisen dadurch leicht Fehler beim Import von Sonderzeichen auf. Der Zeichensatz kann anschließend über Bearbeiten → Datenbank → Eigenschaften → Zusätzliche Einstellungen entsprechend korrigiert werden:

Tabellenquellen für Datenbanken können auch Tabellendokumente sein. Wird aber eine Calc-Tabelle als Grundlage genommen, so ist jedes Editieren der Tabelle ausgeschlossen. Selbst wenn das Calc-Dokument auch noch geöffnet wird, wird dort ein Schreibschutz gesetzt.

Auch eine Verbindung zu Writer-Dokumenten ist möglich. Dort werden dann bestehende Tabellen in Base angezeigt. Auch diese sind wie die Calc-Tabellen schreibgeschützt. Der Name der Tabellen kann im Writer-Dokument über den Navigator oder die Tabelleneigenschaften festgelegt werden.

 

Der Dialog für die Verbindung zu Tabellendokumenten und Writer-Dokumenten ist gleich. Lediglich aus den Schritten ist erkennbar: Beide Dokumenttypen können genutzt werden.

Die einzige Abfrage ist letztlich, an welcher Position das Tabellendokument liegt und ob die Tabelle passwortgeschützt ist. Base öffnet dann das Tabellendokument und übernimmt alle Tabellenblätter mit ihrem Inhalt. Aus der ersten Zeile bildet Base die Feldbezeichnungen, aus den Tabellenblattbezeichnungen die Tabellenbezeichnungen. Auch Daten, die aus externen Quellen in Calc eingebunden sind (z. B. laufend aktualisierte Webseiten), lassen sich so in Base lesen.

Enthält das Tabellenblatt Datenbankbereiche, sichtbar über den Navigator oder Daten → Bereich auswählen, so werden diese Bereiche zusätzlich jeweils als Tabellen angezeigt.

Beziehungen zwischen den Tabellen lassen sich in Base nicht erstellen, da Calc nicht Grundlage für eine relationale Datenbank ist. Auch lassen sich Abfragen nicht über eine Tabelle hinaus erstellen.

Natürlich lassen sich in Calc vorbereitete Daten sehr wohl nach Base importieren und dort dann entsprechend verwerten. Siehe hierzu das Kapitel «Import von Daten aus anderen Datenquellen».

• Hinweis 

Daten aus einer Calc-Tabelle werden in Base automatisch mit einem entsprechenden Format versehen. Allerdings wählt Base ein anderes Format als das Textformat nur dann, wenn alle Zeilen einen entsprechenden Wert enthalten. Das Textformat kann nicht geändert werden und kann dann bei weiteren Verarbeitungen zu Problemen führen, wenn z. B. Zahlen in eine andere Datenbank übertragen werden sollen. Hier hilft es dann, die entsprechenden Standardformatierungen in Calc einzustellen. Das ist für Dezimalzahlen dann eben der Punkt als Dezimaltrenner und keine weitere Formatierung wie z. B. ein Währungszusatz.

Innerhalb von Base sind Daten aus Calc nicht editierbar. Sollen trotzdem Daten verändert werden, so sind die folgenden Schritte zu beachten:

1. 1.Die Base-Datei muss mit einem Zugriff auf die Tabellen geöffnet sein, bevor die damit verbundene Calc-Datei geöffnet wird. 

2. 2.Die Calc-Datei wird mit einem Schreibschutz geöffnet. Hier auf Dokument bearbeiten klicken. 

3. 3.Werden Daten im vorhandenen Datenbereich geändert, so muss in der Base-Tabelle der Button zum Aktualisieren (oder Daten → Aktualisieren) betätigt werden. Die geänderten Daten sind jetzt in der Base-Datei zu sehen. Vorsicht! Die Daten sind in Calc nicht abgespeichert. 

4. 4.Werden Daten unterhalb des Bereiches in einer neuen Zeile hinzugefügt, so bekommt die Tabelle in Base von der zusätzlichen Zeile nichts mit. In diesem Fall die Tabelle schließen und Ansicht → Tabellen aktualisieren im Hauptmenü der Base-Datei betätigen. Danach die Tabelle wieder öffnen und die zusätzliche Zeile erscheint. 

In Calc ist es möglich, auf externe Daten aus dem Internet zuzugreifen. Diese Daten lassen sich mit einer beständigen Aktualisierung versehen. So ist es auch möglich, mit Base eben über Calc auf solche Daten zuzugreifen.

In Calc wird Tabelle → Verknüpfung zu externen Daten… aufgerufen.

Hier wurde als Quelle der Wikipediaartikel zu Bundestagswahlen ausgesucht. Bei dem Artikel lohnt sich zwar nicht die Aktualisierung, aber das Prinzip lässt sich daran auch nachvollziehbar erklären.

Ist der Link zu der externen Datenquelle eingegeben, so muss diese Eingabe mit einem Return betätigt werden. Ansonsten passiert nichts. Erst danach beginnt die Suche nach vorhandenen Inhalten auf der Seite.

Wenn Calc entsprechende Informationen aus der Seite geladen hat erscheinen zuerst die Importoptionen. Da die Tabellen in Wikipedia in dem gewählten Beispiel sowieso eine Mischung aus Text und Zahlen darstellen wird auch Base daraus nur Textfelder machen. Deswegen ist hier z. B. das Erkennen weiterer Zahlen nicht aktiviert worden.

Die Tabellen in dem Wikipediaartikel werden von oben nach unten durchnummeriert. Hier ist die zweite Tabelle HTML_2 ausgewählt, die die prozentualen Anteile für die verschiedenen Parteien bei sämtlichen Bundestagswahlen aufzeigt. Die unteren beiden Einträge sind für die Nutzung in Base nicht geeignet. Bei HTML_all wird der gesamte Inhalt ohne Rücksicht auf Tabellen geladen, bei HTML_tables alle 3 Tabellen auf eine Seite des Calc-Dokumentes gepackt, so dass Base daraus versuchen würde, eine Gesamttabelle zu erstellen.

Jetzt könnte noch die automatische Aktualisierung eingestellt werden, so dass z. B. alle 60 Sekunden im Netz nachgeschaut wird, ob die Daten noch Bestand haben. So etwas macht wohl eher bei Aktienkursen als bei einer Tabelle zur Bundestagswahl Sinn.

Die so eingelesenen Daten brauchen nicht weiter formatiert zu werden. das geschieht in Base. Für die Datenbankdatei ist lediglich wichtig, wie die Tabelle, hier «Bundestagswahlen» heißt. Denn dies ist auch der so erkannte Tabellenname.

Bei Tabellen, die so in Calc eingelesen werden, werden die besten Ergebnisse erzielt, wenn die Vorlage im Internet die Daten sauber in Zeilen und Spalten darstellt. Zeilenumbrüche in einer Zelle führen zu zusätzlichen Datenzeilen, die dann leere Felder in den anderen Spalten hervorrufen. Zusätzliche unbedarfte Formatierungen der Urheber einer solchen Tabelle können dazu führen, dass nach jeder Zeile mit Inhalt eine Leerzeile entsteht. Das werden dann auch leere Tabellenzeilen in Base. Ein Löschen von Zeilen bringt hier nichts, da schließlich der Inhalt regelmäßig aktualisiert wird. Da müsste dann schon innerhalb von Calc aus der Importtabelle in eine weitere Tabelle eingelesen werden, die diese Formatierungsfehler ausgleicht.

 

In der Datenbank stehen jetzt die Namen der Tabelle aus dem Calc-Dokument. Hier wurde die Dokumentansicht für die Tabellen aktiviert, so dass ausschnitthaft direkt zu sehen ist, welcher Inhalt in der Tabelle angezeigt wird.

Die Verbindung zu einem Adressbuch wie z.B. dem Thunderbird-Adressbuch sucht der Assistent automatisch. Er fragt lediglich nach einem Speicherort für die *.odb-Datei, die er erstellen soll.

Alle Tabellen werden dargestellt. Wie in Calc sind die Tabellen aber nicht editierbar. Base macht die Adressen damit nur für Abfragen und z. B. für die Verwendung in Serienbriefen zugänglich.

In Base gibt es die Möglichkeit, eine komplette Datenbank mit Zugriff auf Texttabellen zu erstellen. Gleichzeitig können auch Texttabellen innerhalb einer internen HSQLDB-Datenbank angesprochen werden.

Wie im vorhergehenden Beispiel werden als Datengrundlage in dem folgenden Beispiel *.csv-Dateien genutzt. Über Base wird ein Verzeichnis, in dem die *.csv-Dateien liegen als Datenverzeichnis eingebunden.

Startpunkt ist die Verbindung zu einer bestehenden Datenbank. Hier ist als Format «Text» gewählt.

Der Pfad zu den Textdateien wird ausgesucht. Innerhalb des Verzeichnisses werden später alle dem Dateityp entsprechenden Dateien aufgelistet. Für das *.csv-Format ist hier die zweite Option gewählt.

Bereits bei der Auswahl ist schon deutlich beschrieben: Auf die Tabellen kann nur lesend zugegriffen werden, nicht schreibend.

In der Tabellenansicht sind dann alle Tabellen mit dem Dateinamen aus dem aufgezeigten Verzeichnis ohne die Dateinamenserweiterung zu sehen. Die Aufgaben zum Erstellen von Tabellen stehen nicht zur Verfügung. Die Tabellen selbst sind nur lesbar, nicht schreibbar.

Auch der Zugriff auf die Tabellen mit Abfragen ist beschränkt auf eine Tabelle und keine Funktionen.

Wird eine solche Datenbank genutzt, um einmal kurz in einer *.csv-Datei nach entsprechenden Datensätzen zu suchen oder um eine *.csv-Datei in eine andere Datenbankdatei über die Kopierfunktion einzufügen, so erfüllt diese Text-Datenbank ihren Sinn. Die entsprechende *.csv-Datei wird nur in das definierte Verzeichnis geschoben und kann dann direkt durchsucht oder kopiert werden. Für weitergehende Datenbankaufgaben ist diese Text-Datenbank wohl nicht gedacht.

Die etwas in die Jahre gekommene alte HSQLDB-Version der internen Datenbank wird ab LO 6.1 schrittweise durch eine interne Firebird-Datenbank ersetzt. Seit Version LO 4.2.* ist die interne Firebird-Datenbank erst einmal nur als «experimentelle Funktion» zusätzlich wählbar. Das liegt einfach daran, dass zu dem Zeitpunkt längst noch nicht alle Funktionen richtig integriert werden konnten. Um aber zu sehen, was Firebird leisten kann, wird hier die Verbindung zu einer externen Firebird-Datenbank dargestellt.

Da die Dokumentation dazu nicht ganz so umfangreich ist wie z.B. zu MySQL oder PostgreSQL hier zuerst einmal die wichtigsten Schritte bei der Installation.

Unter Linux stehen für Firebird entsprechende Pakete in der Paketauswahl bereit. Hier muss nach der Installation eigentlich nur noch der Server eingeschaltet werden. Die folgenden Schritte haben unter OpenSUSE 15.0 zu einer funktionierenden Datenbank mit Firebird geführt:

1. 1.Notwendig für die Installationsschritte bis zur funktionierenden Datenbank sind Administratorrechte auf dem Rechner. Dem Systemuser «firebird» sollte ein Passwort zugeordnet werden. 

2. 2.Der Nutzer «firebird» muss sich mit
   su firebird
   auf der Konsole anmelden. 

3. 3.sysdba ist der Nutzername für den Admin-Account. Die folgenden Schritte funktionieren nur, wenn der Firebird Server nicht läuft. 

4. 4.Eine Passwortänderung geht im Terminal als Nutzer «firebird» über:
   isql-fb -user sysdba
   Je nach System kann der Befehl auch isql statt isql-fb lauten. In OpenSUSE ist gibt es andere Pakete, die den Befehl «isql» belegen. 

5. 5.Danach geht es weiter in der SQL-Konsole. Zuerst muss eine leere Datenbank erstellt werden, damit auf die weiteren Befehle zugegriffen werden kann:
   SQL> CREATE DATABASE 'fbtest.fdb';
   SQL> CREATE USER SYSDBA password 'neuesPasswort';
   SQL> commit; 

6. 6.Erst nach diesen Einstellungen kann der Server gestartet werden. 

7. 7.Ein neuer Nutzer sollte erstellt werden:
   SQL> connect localhost:employee.fdb user SYSDBA password neuespasswort;
   Als Antwort hierauf erscheint die Meldung
   Database: localhost:employee.fdb, User: SYSDBA
   Hiernach wird dann eingegeben:
   SQL> CREATE USER lotest password 'libre';
   Der neue Nutzer mit dem Namen lotest und dem Passwort libre wird also erst erstellt, wenn eine Verbindung zu einer Datenbank, hier der zu Firebird gehörigen festen Beispieldatenbank «employee.fdb», existiert. 

8. 8.Danach kann die Datenbank für den neuen Nutzer erstellt werden:
   SQL> CREATE DATABASE 'libretest.fdb' user 'lotest' password 'libre'; 

9. 9.Auf die direkte Nachfrage nach dem Commit muss mit y geantwortet werden:
   Commit current transaction (y/n)?y
   Committing. 

10. 10.Mit
    SQL> quit;
    wird die Eingabe im SQL-Modus des Tools isql-fb beendet. 

Werden die Angaben als Systemadministrator «root» getätigt, so ist die Datenbank nicht dem richtigen Benutzer für den Netzwerkbetrieb zugeordnet. Die Datenbankdatei muss als Nutzer und als Gruppe «firebird» zugewiesen bekommen. Sonst klappt der Kontakt später nicht.

Die direkte Verbindung zu einem Firebird Server ist mit dem internen Treiber möglich. Allerdings bietet die GUI hier zur Zeit keine weitere Hilfe an. Auch funktioniert diese Verbindung nur so lange, wie die interne Datenbankversion Firebird 3 und die Version des Servers gleich sind. Firebird-Dateien für Firebird 4 können mit dem internen Treiber nicht geöffnet werden.

1. 001 [Firebird] 

2. 002 Description = Firebird ODBC driver 

3. 003 Driver64 = /usr/lib64/libOdbcFb.so 

1. 001 [Firebird-libretest] 

2. 002 Description = Firebird database libreoffice test 

3. 003 Driver = Firebird 

4. 004 Dbname = localhost:/srv/firebird/libretest.fdb 

5. 005 SensitiveIdentifier = Yes 

Diese beiden Dateien liegen bei einem Linux-System im Verzeichnis /etc/unixODBC. Die Variable SensitiveIdentifier muss auf jeden Fall auf «Yes» stehen, damit die Eingabe in Tabellen funktioniert, deren Namen und Feldbezeichnungen nicht in Großbuchstaben angegeben sind.

Wird eine Serverdatenbank nicht benötigt, dann ist auch die direkte Verbindung zu einer Firebird-Datei möglich. Hier muss lediglich, wie z.B. bei Tabellendokumenten, der Pfad zu der Firebird-Datei herausgesucht werden. Die Verbindung wird dann automatisch hergestellt. Die Firebird-Datei muss dazu allerdings ab LibreOffice 5.3 mit einer Firebird-Version ab Firebird 3 erstellt worden sein. Über den Assistenten kann so eine Datei direkt erstellt werden.

Aus einer internen Datenbankdatei lässt sich eine externe Datenbankdatei erstellen:

Die externe Datenbankdatei kennt noch keine Benutzerverwaltung. Alle Tabellen, Ansichten und Trigger sind dort unter dem Administrationsnutzer von Firebird (SYSDBA) erstellt worden, können aber durch den aktuellen Benutzer der Datenbankdatei genauso weiter benutzt werden.

Die Schritte wie bei der Erstellung einer neuen Datenbank sind nicht notwendig. Die folgenden Schritte haben unter OpenSUSE 15.3 zu einer funktionierenden Serverdatenbank mit Firebird 3 geführt:

1. 1.Notwendig für die Installationsschritte bis zur funktionierenden Datenbank sind Administratorrechte auf dem Rechner. Der Firebird Server muss ausgeschaltet sein. 

2. 2.Die externe Firebird-Datei «extern.fdb» wird in das Verzeichnis kopiert, das von dem Firebird Server als Serververzeichnis angesehen wird. Hier ist das /srv/firebird. 

3. 3.Der Datei wird der Nutzer und die Gruppe «firebird» zugewiesen. 

4. 4.Dem Systemuser «firebird» sollte ein Passwort zugeordnet werden. 

5. 5.Der Nutzer «firebird» muss sich mit
   su firebird
   auf der Konsole anmelden. 

6. 6.Auf der Konsole wird
   isql-fb -user SYSDBA extern.fdb
   eingegeben. Dadurch wird der Nutzer SYSDBA mit der Datenbank verbunden. 

7. 7.Anschließend wird mit
   SQL> CREATE OR ALTER USER SYSDBA PASSWORD 'neuesPasswort';
   ein Passwort erstellt, das für den Systemnutzer, der auch Standardnutzer aller internen Datenbanken von Base ist, genutzt werden kann. 

8. 8.Mit
   SQL> quit;
   wird die Eingabe im SQL-Modus des Tools isql-fb beendet. 

9. 9.Jetzt wird der Firebird Server gestartet. 

10. 10.Die JDBC-Verbindung zur Datenbank extern.fdb wird mit dem Nutzer SYSDBA und dem entsprechenden Passwort erstellt. 

11. 11.Über Extras → SQL wird mit
    CREATE USER neuerUser PASSWORD 'neuesUserPasswort';
    ein neuer Nutzer erstellt. 

12. 12.Verbindet sich der neue Nutzer mit der Serverdatenbank, so kann er zwar die Tabellen sehen, bei einem Klick auf die Tabellen erscheint aber, dass er keine Rechte zum Lesen der Tabellen hat. Dies liegt daran, dass die (vorher interne) Datenbankdatei nur den Nutzer SYSDBA kennt. Daher muss der Nutzer SYSDBA dem neuen Nutzer alle möglichen Rechte zuweisen:
    Über Extras → SQL werden die Rechte für <neuerUser> eingestellt. Die allgemeine Administrationsrolle zu der aktuellen Datenbank wird über
    GRANT RDB$ADMIN TO neuerUser;
    zugewiesen. 

13. 13.Nach dem Einloggen des neuen Nutzers muss dieser explizit angeben, dass er die Rolle gerade wahrnehmen will. Über Extras → SQL (oder per Makro) macht dies
    SET ROLE RDB$ADMIN;
    Dies ist eine Einstellung, die bei jedem Login erfolgen muss.
    Alternativ dazu kann auch zu den entsprechenden Tabellen und Ansichten ein entsprechendes Nutzerrecht vergeben werden:
    GRANT ALL ON TABLE "Tabellenname" TO USER neuerUser;
    Diese Zuweisung ist von der ROLE unabhängig. Sie muss deshalb nicht bei jedem Start extra ausgewählt werden. 

Unter Firebird und einigen anderen externen Datenbanken, soweit der Treiber das zulässt, steht über Extras → Benutzerverwaltung… ein Dialog zur Verwaltung der Benutzerrechte für die verschiedenen Tabellen zur Verfügung. Leider scheint diese Benutzerverwaltung grundsätzlich nicht zu funktionieren. Zumindest das Hinzufügen von neuen Nutzern über Verwalten wäre schon sinnvoll. So könnten auch die Passwörter entsprechend in der GUI gesetzt werden. Bei den Zugriffsrechten wird auch grundsätzlich außer den Tabellennamen nichts angezeigt. Die Markierfelder reagieren hier überhaupt nicht.

Für die direkten Verbindungen zu MySQL/MariaDB oder auch PostgreSQL ist die Benutzerverwaltung von vornherein ausgeschlossen und startet gar nicht erst.

SQLite-Datenbanken bestehen aus einer einzigen Datei. Diese Datei kann irgendwo im Dateisystem gespeichert werden und muss nur über einen entsprechenden Treiber mit Base verbunden werden.

Das Erstellen einer Datenbank beschränkt sich darauf, eine leere Datei in einem Verzeichnis abzulegen. Es ist nicht einmal erforderlich, der leeren Datei eine bestimmte Dateiendung zu geben. Unter Linux reicht es, eine einfache Textdatei zu erstellen. Die Datei wird dann mit dem Namen libretest.db versehen. Bei der Erstellung kann es passieren, dass bereits Absätze vorhanden sind. Diese Absätze sollten gelöscht werden, so dass der Inhalt der Datei 0 Byte groß ist.

Natürlich lässt sich eine leere Datei auch auf der Konsole erstellen, die bei der Installation des Treibers mitinstalliert wird:

1. 001 sqlite3 libretest.db 

erstellt die leere Datenbankdatei. Dabei wird dann die SQLite-Konsole geöffnet. Die Datei ist noch nicht in dem Verzeichnis sichtbar, in dem der Befehl ausgeführt wird. Auf der Konsole wird jetzt nur noch

1. 001 .exit 

eingegeben und die leere Datei wird geschrieben.

Unter Linux wird der ODBC-Treiber des Systems über die Paketverwaltung installiert. Die Einstellungen in der odbcinst.ini werden dabei automatisch vorgenommen.

1. 001 [SQLITE3] 

2. 002 Description=SQLite ODBC 3.X 

3. 003 Driver=/usr/lib64/libsqlite3odbc.so 

4. 004 Setup=/usr/lib64/libsqlite3odbc.so 

5. 005 Threading=2 

6. 006 FileUsage=1 

7. 007 UsageCount=1 

In der odbc.ini wird dann die Verbindung zu der vorher erstellten Datei vorgenommen. Die Datei wird anschließend über die entsprechende Bezeichnung, hier Sqlite3-libretest, über ODBC mit Base verbunden.

1. 001 [Sqlite3-libretest] 

2. 002 Description = SQLite database libreoffice test 

3. 003 Driver= SQLITE3 

4. 004 Database= /home/<nutzername>/Dokumente/LibreOffice/libretest.db 

Nachdem die *.jar-Archiv herunter geladen und in den Class Path eingebunden wurde wird mit folgenden Angaben auf die Datenbank zugegriffen:

JDBC URL:       jdbc:sqlite:/home/<nutzername>…/libretest.db

Treiberbezeichnung: org.sqlite.JDBC

Vor allem bei Verbindungen zu externen Datenbanken kann es hin und wieder vorkommen, dass eine Verbindung nicht wie gewünscht einwandfrei funktioniert. Mal ist der Zeichensatz nicht korrekt, ein anderes Mal funktionieren Unterformulare nicht einwandfrei oder es ist einfach etwas an den grundsätzlichen Verbindungsparametern zur Datenbank geändert worden.

Die folgenden Screenshots zeigen die Möglichkeit auf, wie z.B. die Verbindungsparameter zu einer externen PostgreSQL-Datenbank im Nachhinein geändert werden können.

Über Bearbeiten → Datenbank werden die Einstellungsmöglichkeiten «Eigenschaften», «Verbindungsart» und «Erweiterte Einstellung» aufgerufen.

Falls sich der Name der Datenquelle geändert hat, kann dies hier geändert werde. Bei einer Verbindung über ODBC wird ja der Name, mit dem die Datenbank aufgerufen werden kann, in der odbc.ini festgelegt. Der Name ist in der Regel nicht gleich dem eigentlichen Datenbanknamen in PostgreSQL.

Gibt es Probleme mit dem Zeichensatz? Diese Probleme können eventuell in dem zweiten Reiter der Datenbankeigenschaften gelöst werden.

Auch eine zusätzliche spezielle Einstellung des Treibers ist möglich, wenn eventuell ein Parameter ausgeführt werden soll, der zur Zeit nicht bereits in der odbc.ini steht.

Wird die Verbindungsart ausgewählt, so kann der gesamte Kontakt zur Datenquelle geändert werden. Die darauf folgenden Schritte sind gleich denen des Datenbankassistenten ab Schritt 2. So kann z.B. von einer ODBC- auf eine JDBC- oder gar eine direkte Verbindung über die internen Treiber von LO gewechselt werden. Dies ist vor allem dann sinnvoll, wenn zuerst einmal ausgetestet werden soll, welche Verbindungsart zu dem eigenen Projekt am besten passt.

Je nach Datenbanksystem gibt es unterschiedliche Befehle um automatisch hoch zählende Werte zu erzeugen. Soll so etwas erreicht werden, was der Treiber zur Zeit nicht direkt ermöglicht, dann ist an dieser Stelle Handarbeit angesagt. Dabei ist sowohl ein Befehl für das Erstellen eines Auto-Wert-Feldes als auch ein Befehl zur Abfrage des zuletzt erstellten Wertes notwendig.

Die über Bearbeiten → Datenbank → Erweitere Einstellungen erreichbaren besonderen Einstellungen beeinflussen das Zusammenspiel von externer Datenbank und Base auf die unterschiedliche Art und Weise. Manche Einstellungen sind bereits ausgegraut, da sie für die zugrundeliegende Datenbank nicht änderbar sind. In dem obigen Beispiel wurde Benannte Parameter durch '?' ersetzen ausgewählt. Es hatte sich gezeigt, dass sonst bei PostgreSQL die Weitergabe von Werten von einem Hauptformular zum Unterformular nicht funktionierte. Erst mit dieser Einstellung funktionierten die weitergehenden Formularkonstruktionen aus dem Kapitel «Formulare» dieses Handbuches korrekt.

Leider sind manchmal nicht alle möglichen erweiterten Einstellungen tatsächlich in der GUI verfügbar. Gegebenenfalls kann dann der Zugriff auf die in der *.odb-Datei befindlichen content.xml helfen. Hier ein Beispiel, das gerade beim Umstieg von LO 6.0 zu LO 6.1 Probleme bereitete: Unterabfragen in MySQL waren nicht mehr möglich, weil die Weitergabe des verbindenden Wertes (Parameter) unterbunden wurde. Das gleiche Problem hat auch Firebird, wenn die Firebird-Datenbank über den Migrationsassistenten erstellt wurde - zumindest in allen Versionen LO 6.*.

Der nicht funktionierende Code:

1. 001 <db:driver-settings db:system-driver-settings="" db:base-dn="" 

2. 002 db:parameter-name-substitution="false"/> 

Wird dieser Code geändert auf

1. 001 <db:driver-settings db:system-driver-settings="" db:base-dn=""/> 

so funktionieren die Unterformulare wieder mit der *.odb-Datei.

Alternativ kann auch das folgende Makro von der migrierten Base-Datei aus gestartet werden:

1. 001 SUB FB_Parameter 

2. 002    DIM oSettings AS OBJECT 

3. 003    oSettings = ThisComponent.DataSource.Settings 

4. 004    oSettings.ParameterNameSubstitution = True 

5. 005 END SUB 

Nach einmaligem Start des Makros ist der Eintrag in der Base-Datei komplett verschwunden, sofern die Base-Datei einmal abgespeichert wurde.

Grundsätzlich ist es in SQL möglich, Tabellennamen und Feldnamen ohne Maskierung zu schreiben. Ein Code wie

1. 001 SELECT VORNAME, NACHNAME FROM PERSONENTABELLE 

funktioniert genauso wie

1. 001 SELECT "VORNAME", "NACHNAME" FROM "PERSONENTABELLE" 

Je nach Datenbanksystem setzt Base die Maskierung mit «doppelten Anführungszeichen oben» automatisch im Abfrageeditor und auch bei der Eingabe über Extras → SQL. Bei den internen Datenbanksystemen HSQLDB und Firebird kann es aber schon Probleme geben, wenn Tabellennamen und Feldnamen nicht grundsätzlich groß geschrieben werden. Werden die folgenden Eingaben in dem Abfrageeditor im SQL-Modus eingegeben und dabei die direkte Ausführung von SQL ausgewählt, so führt das bei einer Eingabe zu einer Fehlermeldung:

1. 001 SELECT "Vorname", "Nachname" FROM "PersonenTabelle" 

funktioniert, wenn eben die Felder auch Kleinbuchstaben enthalten. Das kann auch auf Sonderzeichen ausgedehnt werden.

1. 001 SELECT Vorname, Nachname FROM PersonenTabelle 

funktioniert hingegen nicht, weil der SQL-Code direkt an die Datenbank weiter gegeben wird ohne die Bezeichner zu maskieren. Die interne Datenbank sucht dann nach einer Tabelle und Feldern in Großbuchstaben, die aber nicht vorhanden sind.

Bei externen Datenbanken hängt die Maskierung von dem entsprechenden Datenbanksystem ab. Hier ist manchmal auch keine Maskierung notwendig. Für MySQL/MariaDB schreibt Base je nach Treiber direkt die passende Maskierung in den SQL-Code, der durch den Abfrageeditor erstellt wird:

1. 001 SELECT `Vorname`, `Nachname` FROM `PersonenTabelle` 

Die Maskierung für MySQL und MariaDB ist also hier nicht das doppelte Anführungszeichen sondern der Gravis `.

Inhalte wie Texte und Datumsangaben werden grundsätzlich mit einem «einfachen Anführungszeichen oben» maskiert.

1. 001 SELECT "Vorname", "Nachname", "Geburtsdatum"  

2. 002 FROM "PersonenTabelle" 

3. 003 WHERE "Nachname" = 'Müller' AND "Geburtsdatum" = '2001-03-21'  

Kommt ein «einfaches Anführungszeichen oben» auch im Text selbst vor, so ist es ebenfalls mit einem «einfachen Anführungszeichen oben» zu maskieren.

1. 001 SELECT "Gegenstände" FROM "Tabelle" WHERE "Besitzer" = 'Robert''s' 

Zahlen benötigen keine Maskierung. Hier ist lediglich zu beachten, dass Dezimalzahlen den Punkt als Trenner benötigen.

Unter Extras → Optionen → LibreOffice Base → Verbindungen gibt es die Möglichkeit, die Aufbewahrungszeit für einen Treiber einzustellen.

Hierbei geht es nicht um die Zeit, nach der eine Verbindung bei fehlender Aktivität, wie weiter oben beschrieben, nach einer bestimmten Zeit unterbrochen wird. Vielmehr soll eine Verbindung, die ein Nutzer einmal erstellt hat, anschließend auch noch gegebenenfalls für einen anderen Nutzer zur Verfügung gestellt werden. Aus dem Grunde stehen in dem Verbindungspool auch alle Treiber zur Verfügung, die LibreOffice mitliefert.

Die Nutzung dieser Einstellungen scheint nur dann sinnvoll zu sein, wenn über Makros direkt auf einen Datenbank ohne Umweg über die Datenbankdatei zugegriffen werden soll. Dann kann von

1. 001 oManager = CreateUnoService("com.sun.star.sdbc.DriverManager") 

nach

1. 001 oManager = CreateUnoService("com.sun.star.sdbc.ConnectionPool") 

gewechselt werden.

Die Aufbewahrung ist damit unabhängig von den eigentlichen Datenbankeinstellungen z.B. in MySQL/MariaDB oder PostgreSQL, bei denen es um das Halten der Verbindung zur Datenbank geht. Die Zeitabschnitte zum Halten der Verbindung sind standardmäßig bei MySQL/MariaDB 8 Stunden, bei PostgreSQL sogar unbegrenzt.

Die Verbindung zu Datenbankservern in Netzen kann durch eine SSH-Verknüpfung zum Server mit einem SSH-Tunnel sicher gestaltet werden. In dem folgenden Beispiel sei die IP des Ubuntu-Servers 192.168.178.32. Der Kontakt wird hier zu einer PostgreSQL Datenbank aufgenommen.

Auf dem Server existiert ein Benutzer 'lotest' mit dem Passwort 'libre'.

Die WebDav-Einstellungen für das Laden von Dateien über Datei → Vom Server öffnen… sind in dem folgenden Dialog für einen internen Server ersichtlich:

 

Verbindung im lokalen Netz zu einer Nextcloud-Installation

Dabei ist darauf zu achten, dass der Host ohne den Zusatz http:// oder dav:// oder webdav:// aufgeführt wird. Sonst wird die Verbindung falsch aufgetrennt und irrtümlich http, dav oder webdav als Host gelesen. Das wird dann deutlich, wenn der Dialog beim nächsten Öffnen unter Root: mit dem Eintrag von //192.168.178.32 (oder eben dem Hostnamen nach draußen) beginnt.

Wird der Dialog zum Öffnen der Dateien vom Server zum ersten Mal nach dem Öffnen von LibreOffice genutzt, so erfolgt die Benutzer- und Passwortabfrage.

Auf diesem Weg können Datenbankdateien geöffnet, aber nur unterschiedlich genutzt werden. Beim Zugriff auf eine interne Hsqldb erscheint der folgende Hinweis:

Es ist also nicht möglich, die Tabellen überhaupt zu sehen. Die interne Hsqldb braucht dazu zwingend den Zugriff auf den lokalen Rechner.

Firebird läuft da etwas problemloser. WebDav lädt die Datei. Die Datenbank steht für Einträge und Recherchen auch über bereits erstellte Formulare zur Verfügung. Auch Berichte werden ausgeführt. Eine Erstellung neuer Formulare, Abfragen, Tabellen usw. über die grafische Benutzeroberfläche ist allerdings nicht möglich. Hierzu muss also die Datei erst auf dem lokalen Rechner bearbeitet werden und kann dann anschließend zur Nutzung über die Cloud wieder hoch geladen werden.

Dass eine Bearbeitung der *.odb-Datei nicht möglich ist ließe sich natürlich auch vorteilhaft nutzen. Wird z. B. eine Verbindung zu einem lokal auf dem Server laufenden PostgreSQL-Server genutzt, so läuft die Verbindung gleich dem, was auf dem eigenen lokalen Server eingestellt werden müsste. Es könnte also über die Cloud eine Bedienoberfläche zur Verfügung gestellt werden, die durch andere Benutzer nicht verändert werden kann, sehr wohl aber die Funktionalität der Datenbank voll unterstützt.

Bestimmte Fehler bei Datenbankverbindungen tauchen bereits seit Beginn von LibreOffice auf. Diese Fehler werden hier aufgelistet, sofern dafür ein entsprechender Workaround existiert.

wird das Feld nicht leer, sondern mit den Zahlen '1' für 'Ja' und '0' für 'Nein' dargestellt.

Ebenfalls mit der direkten Verbindung lässt sich über die GUI keine Abfrage mit mehr als einer Tabelle erstellen ohne dass die Abfrage anschließend schreibgeschützt ist. Wird hier der Tabellenname und der automatisch erstellte Alias entfernt, so ist wie bei anderen Datenbankverbindungen eine Eingabe möglich.

1. 001 … FROM `test`.`tbl_Person` `tbl_Person`, `test`.`tbl_Hobbies` `Hobbies` … 

sollte schlicht geändert werden in

1. 001 … FROM `tbl_Person`, `Hobbies` … 

Danach sind Eingaben in die Abfrage genauso wie bei den internen Datenbanken und bei der JDBC-Verbindung zur MariaDB möglich.