Um die Barcode-Druckfunktion nutzen zu können, muss der Font «ean13.ttf» installiert sein. Dieser Font ist frei verfügbar.

EAN13-Barcodes können mittels «ean13.ttf» folgendermaßen erstellt werden:

Siehe hierzu die Abfrage "Barcode_EAN13_ttf_Bericht" der Beispieldatenbank «Medien_ohne_Makros»

Vor allem bei Zahlenwerten besteht große Verwechselungsgefahr. In der Datenbank steht z.B. häufig im Primärschlüssel der Datentyp «INTEGER». Wird jetzt per Makro ausgelesen, so muss dort die aufnehmende Variable den Typ «Long» haben, da diese vom Umfang her mit «INTEGER» aus der Datenbank übereinstimmt. Der entsprechende Auslesebefehl heißt dann auch «getLong».

In der eingebauten HSQLDB bzw. in Firebird sind die folgenden Funktionen verfügbar. Ein paar Funktionen können leider nur dann genutzt werden, wenn in der Abfrage «SQL-Kommando direkt ausführen» gewählt wurde. Dies verhindert dann gleichzeitig, dass die Abfragen editierbar bleiben.

Funktionen, die mit der grafischen Benutzeroberfläche zusammenarbeiten, sind gekennzeichnet mit GUI. Funktionen, die nur über «SQL-Kommando direkt ausführen» ansprechbar sind, sind gekennzeichnet mit GUI.

Bei den Funktionen gibt es solche, die mit der HSQLDB laufen, nicht aber mit der eingebauten Version von Firebird - und umgekehrt. Ist der Datenbankname grün dargestellt, so ist die Funktion verfügbar und gibt ordnungsgemäße Werte aus. Ist der Datenbankname rot und durchgestrichen dargestellt, so ist die Funktion nicht verfügbar oder aber, was deutlich bedenklicher ist, verfügbar, nur eben mit falschen Ergebnissen. Das ist dann mit dem Zusatz (Bug) gekennzeichnet.

Window-Funktionen bei Firebird Window-Funktionen2 filtern nicht die Ergebnismenge einer Abfrage. Die Ergebnisse der Funktionen werden zusätzlich in entsprechenden Spalten angegeben. Window-Funktionen können in der SELECT-Liste oder in der ORDER BY-Definition vorkommen. In den Window-Funktionen ist eine OVER-Klausel zwingend enthalten. In dieser Klausel können Partitionierungen und Sortierungen vorgenommen werden. <Funktionsname>() OVER (PARTITION BY … | ORDER BY …)
Ranking-Funktionen
RANK() OVER (ORDER BY …)	Kann zur Bestimmung der Reihenfolge in einer Datenmenge eingesetzt werden. Gleiche Werte werden dabei mit der gleichen Position versehen. Die Position wird wie bei Sportwettkämpfen erstellt. Richtet sich nach der Sortierung, die angegeben wird. GUI
RANK() OVER (PARTITION BY … ORDER BY …)	Gleiche Funktion wie oben, nur mit der Ergänzung der Partitionierung. Hier ist die Reihenfolge abhängig vom Feld "Geschlecht".
DENSE_RANK() OVER (ORDER BY …)	Kann zur Bestimmung der Reihenfolge in einer Datenmenge eingesetzt werden. Gleiche Werte werden dabei mit der gleichen Position versehen. Dabei rücken tiefer liegende Werte auf. Richtet sich nach der Sortierung, die angegeben wird. GUI
ROW_NUMBER() OVER (ORDER BY …)	Kann zur Bestimmung der laufenden Nummer in einer Datenmenge eingesetzt werden. Gleiche Werte werden dabei nach dem Primärschlüssel zusätzlich sortiert. Richtet sich nach der Sortierung, die angegeben wird. GUI
Navigationsfunktionen
FIRST_VALUE(…) OVER (ORDER BY …)	001 SELECT "ID", "Name", "Laufzeit",  002 FIRST_VALUE("Laufzeit") OVER (ORDER BY "Laufzeit")  003 FROM "Starter"  Hier wird der Wert für die niedrigste Laufzeit neben angezeigten aktuellen Laufzeit angegeben. Es könnte also direkt die Differenz zum ersten Platz ausgerechnet werden. GUI
LAG(…,[offset,[default]]) OVER (ORDER BY …)	001 SELECT "ID", "Name", "Laufzeit",  002 LAG("Laufzeit") OVER (ORDER BY "Laufzeit")  003 FROM "Starter"  Hier wird der Wert für die Laufzeit angezeigt, die die Person gelaufen hat, die direkt vorher ins Ziel gekommen ist. Es könnte also direkt die Differenz zur vorher durchs Zeile gekommenen Person ausgerechnet werden. Wird ein offset angegeben, so kann auch der Abstand zu weiter vorher durchs Ziel gekommenen Personen ermittelt werden. Als default wird ohne Angabe NULL gesetzt, ansonsten der korrekt formatierte Wert für das entsprechende Feld, hier z. B. '00:00:00'. GUI
LAST_VALUE(…) OVER (ORDER BY …)	Hier wird der zuletzt ausgelesene Wert wieder gegeben. Dies ist also nicht der Wert für die zuletzt durchs Ziel gekommene Person, sondern der aktuelle Wert, der auch so in der Laufzeit steht. GUI
LEAD(…,[offset,[default]]) OVER (ORDER BY …)	Dies ist die Umkehrung der Funktion von LAG. Es wird die Zeit angezeigt, die die Person gelaufen ist, die direkt nach der aktuellen Position ins Ziel gekommen ist. Wird ein offset angegeben, so kann auch der Abstand zu weiter hinten durchs Ziel gekommenen Personen ermittelt werden. Als default wird ohne Angabe NULL gesetzt, ansonsten der korrekt formatierte Wert für das entsprechende Feld, hier z. B. '00:00:00'. GUI
NTH_VALUE(…,offset) [FROM {FIRST | LAST}] OVER (ORDER BY …)	001 SELECT "ID", "Name", "Laufzeit",  002 NTH_VALUE("Laufzeit",1) OVER (ORDER BY "Laufzeit")  003 FROM "Starter"  Ein offset muss angegeben werden. Die obige Abfrage gibt mit dem offset '1' genau das gleiche Ergebnis wie FIRST_VALUE, kann durch das offset aber auf die verschiedenen anderen Werte eingestellt werden. Standardmäßig wird vom ersten Wert (FROM FIRST) aus ermittelt. Ansonsten vom zuletzt ermittelten Wert. GUI
Aggregatfunktionen als Windowfunktionen Alle Aggregatfunktionen können auch als Windowfunktionen erstellt werden. Damit entfällt die Gruppierungsanweisung (die darüber hinaus die einzelnen Datensätze nicht mehr komplett anzeigt) oder die Notwendigkeit, innerhalb einer Abfrage eine separate Unterabfrage zu erstellen. Alle Aggregatfunktionen können genutzt werden. Hier nur ein Beispiel für die Nutzung von SUM.
SUM(…) OVER (PARTITION BY …)	Die Summierung erfolgt nach der Ausgabe des gesamten Inhaltes der Tabelle. Keine Feld muss gruppiert werden. Die Summe wird für das Feld "Betrag" abhängig von der "RechnungsNr" berechnet. GUI
SUM(…) OVER (PARTITION BY … ORDER BY …)	Wird zusätzlich eine Sortierung vorgenommen, so wird die laufende Summe ermittelt. In der 2. Zeile also die Summe von Zeile 1 und 2, in der 3. Zeile dann die Summe von Zeile 1 und 2 und 3. Solch ein Abfrageergebnis ist sonst nur durch korrelierende Unterabfragen möglich. GUI

Die folgenden Probleme können bei der Migration von Datenbanken der internen HSQLDB 1.8.0.10 zu der internen Firebird 3.0 auftauchen.

• •Tabellennamen, Spaltennamen usw. sind in der HSQLDB von der Länge nicht begrenzt. Bei Firebird hingegen gilt eine Grenze von maximal 31 Zeichen. 

• •Texttabellen können in der HSQLDB zum Lesen, Schreiben und Ändern von Daten genutzt werden. Zur Zeit funktionieren Texttabelle in Firebird hingegen gar nicht, weil die Standardeinstellungen dafür bei der internen Datenbank ausgeschaltet sind. Selbst bei funktionierenden Texttabellen unterscheidet sich das Format der Tabellen, so dass z.B. keine *.csv-Dateien benutzt werden können. Außerdem ist das Ändern und Löschen von Daten in Firebird-Texttabellen nicht erlaubt. 

• •Unterformulare funktionieren nach der Nutzung des Migrationsassistenten nicht. Hier muss die Datenbankdatei mit einem Packprogramm geöffnet werden. Die content.xml muss zum Bearbeiten geöffnet werden. Der Eintrag <db:driver-settings db:system-driver-settings="" db:base-dn="" db:parameter-name-substitution="false"/> benötigt statt des false ein true. Entweder ist hier also true einzutragen oder der gesamte Inhalt db:parameter-name-substitution="false" zu löschen.
  Alternativ kann auch das folgende Makro von der migrierten Base-Datei aus gestartet werden:
  SUB FB_Parameter
    DIM oSettings AS OBJECT
    oSettings = ThisComponent.DataSource.Settings
    oSettings.ParameterNameSubstitution = True
  END SUB
  Nach einmaligem Start des Makros ist der Eintrag in der Base-Datei komplett verschwunden, wenn die Base-Datei anschließend abgespeichert wird. 

• •Sollen Bilder in der Datenbank gespeichert werden, so ist der Datentyp BLOB [BLOB] statt Bild [BLOB] zu währen. Nur Inhalte aus BLOB [BLOB] werden im grafischen Kontrollfeld angezeigt. 

• Hinweis 

In Abfragen lassen sich Felder miteinander verknüpfen. Aus zwei Feldern in

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

wird durch

1. 001 SELECT "Vorname"||' '||"Nachname" FROM "Tabelle" 

Einer Schaltfläche können verschiedene uno-Befehle direkt zugeordnet werden. Dafür muss unter Eigenschaften: Schaltfläche → Aktion → Dokument/Webseite öffnen gewählt werden sowie z. B. als URL → .uno:RecSearch zum Öffnen der Suchfunktion eingetragen werden. Manchmal muss zusätzlich beachtet werden, dass Fokussieren bei Klick → Nein angewählt wird, wenn bestimmte Aktionen direkt auf ein Formularfeld zugreifen sollen, das dafür den Focus braucht, wie z. B. .uno:Paste, das den Inhalt aus der Zwischenablage einfügen kann.

Die folgende Liste gibt nur wenige Befehle wieder. Sämtliche Befehle aus der Navigationsleiste sind ja bereits in der Schaltfläche so verfügbar, könnten aber auch über die uno-Befehle erstellt werden. Viele Befehle lassen sich auch über den Makrorekorder ermitteln, der häufig diese uno-Befehle über einen Dispatcher aufruft. UNO-Befehle können auch z. B. über Extras → Anpassen → Symbolleisten → Beschreibung in jedem LO-Dokument ermittelt werden.

Innerhalb von HSQLDB-Datenbanken wird in dem Bereich "INFORMATION_SCHEMA" die Information über alle Tabelleneigenschaften sowie ihre Verbindung untereinander abgelegt. Diese Informationen ermöglichen in Base bei der Erstellung von Makros, Prozeduren mit weniger Parametern zu starten. Eine Anwendung findet sich in der Beispieldatenbank unter anderem im Modul «Wartung» in der Prozedur «Tabellenbereinigung» für die Ansteuerung des Dialoges.

In einer Abfrage können die einzelnen Informationen sowie sämtliche dazugehörigen Felder auf die folgende Art ermittelt werden.

1. 001 SELECT * FROM "INFORMATION_SCHEMA"."SYSTEM_ALIASES" 

Im Gegensatz zu einer normalen Tabelle ist es hier notwendig, dem jeweiligen folgenden Begriff "INFORMATION_SCHEMA" voranzustellen.

1. SYSTEM_ALIASES

   SYSTEM_ALLTYPEINFO

   SYSTEM_BESTROWIDENTIFIER

   SYSTEM_CACHEINFO

   SYSTEM_CATALOGS

   SYSTEM_CHECK_COLUMN_USAGE

   SYSTEM_CHECK_CONSTRAINTS

   SYSTEM_CHECK_ROUTINE_USAGE

   SYSTEM_CHECK_TABLE_USAGE

   SYSTEM_CLASSPRIVILEGES

   SYSTEM_COLUMNPRIVILEGES

   SYSTEM_COLUMNS

   SYSTEM_CROSSREFERENCE

   SYSTEM_INDEXINFO

   SYSTEM_PRIMARYKEYS

   SYSTEM_PROCEDURECOLUMNS

   SYSTEM_PROCEDURES

   SYSTEM_PROPERTIES

   SYSTEM_SCHEMAS

   SYSTEM_SEQUENCES

   SYSTEM_SESSIONINFO

   SYSTEM_SESSIONS

   SYSTEM_SUPERTABLES

   SYSTEM_SUPERTYPES

   SYSTEM_TABLEPRIVILEGES

   SYSTEM_TABLES

   SYSTEM_TABLETYPES

   SYSTEM_TABLE_CONSTRAINTS

   SYSTEM_TEXTTABLES

   SYSTEM_TRIGGERCOLUMNS

   SYSTEM_TRIGGERS

   SYSTEM_TYPEINFO

   SYSTEM_UDTATTRIBUTES

   SYSTEM_UDTS

   SYSTEM_USAGE_PRIVILEGES

   SYSTEM_USERS

   SYSTEM_VERSIONCOLUMNS

   SYSTEM_VIEWS

   SYSTEM_VIEW_COLUMN_USAGE

   SYSTEM_VIEW_ROUTINE_USAGE

   SYSTEM_VIEW_TABLE_USAGE

Die folgende Abfrage gibt z.B. eine komplette Übersicht über alle in der Datenbank genutzten Tabellen mit Feldtypen, Primärschlüsseln und Fremdschlüsseln:

1. 001 SELECT  

2. 002    "A"."TABLE_NAME",  

3. 003    "A"."COLUMN_NAME",  

4. 004    "A"."TYPE_NAME",  

5. 005    "A"."NULLABLE",  

6. 006    "B"."KEY_SEQ" AS "PRIMARYKEY",  

7. 007    "C"."PKTABLE_NAME" || '.' || "C"."PKCOLUMN_NAME" AS "FOREIGNKEY FOR"  

8. 008 FROM "INFORMATION_SCHEMA"."SYSTEM_COLUMNS" AS "A"  

9. 009    LEFT JOIN "INFORMATION_SCHEMA"."SYSTEM_PRIMARYKEYS" AS "B"  

10. 010    ON ( "B"."TABLE_NAME" = "A"."TABLE_NAME" AND "B"."COLUMN_NAME" =  

          "A"."COLUMN_NAME" )  

11. 011    LEFT JOIN "INFORMATION_SCHEMA"."SYSTEM_CROSSREFERENCE" AS "C"  

12. 012    ON ( "C"."FKTABLE_NAME" = "A"."TABLE_NAME" AND "C"."FKCOLUMN_NAME" =  

          "A"."COLUMN_NAME" )  

13. 013 WHERE "A"."TABLE_SCHEM" = 'PUBLIC' 

Die Firebird-Informationstabellen sind deutlich mehr gesplittet als die der HSQLDB. So stehen z.B. Tabellennamen, Feldnamen und Feldtypen nicht zusammen in einer Tabelle, sondern müssen über mehrere Tabellen hinweg zusammen gebracht werden:

1. 001 SELECT  

2. 002    "a".RDB$RELATION_NAME AS "Tables",  

3. 003    "a".RDB$FIELD_NAME AS "Fields",  

4. 004    "c".RDB$TYPE_NAME AS "Types",  

5. 005    "a".RDB$Field_POSITION AS "Fieldposition",  

6. 006    "a".RDB$NULL_FLAG AS "Nullflag" 

7. 007 FROM RDB$RELATION_FIELDS AS "a", RDB$FIELDS AS "b", RDB$TYPES AS "c"  

8. 008 WHERE "a".RDB$FIELD_SOURCE = "b".RDB$FIELD_NAME 

9. 009    AND "b".RDB$FIELD_TYPE = "c".RDB$TYPE  

10. 010    AND "c".RDB$FIELD_NAME = 'RDB$FIELD_TYPE' 

11. 011    AND "a".RDB$SYSTEM_FLAG = 0 

12. 012 ORDER BY "Tables", "Fieldposition" 

Hiermit wird eine Übersicht über alle selbst erstellten Tabellen mit den Feldnamen, Feldtypen, Feldpositionen innerhalb der Tabelle und der Information, ob sie leer sein dürfen, ermöglicht. Um den Feldtypen zuordnen zu können muss also über die Tabelle "RDB$FIELD_TYPE" zur Tabelle "RDB$TYPE" verbunden werden.

Leider stimmen die dort aufgeführten Typen nur mit denen überein, die intern von Firebird genutzt werden. Sie lauten anders als die, die in dem Tabelleneditor vorkommen. Hier ein Code, um die entsprechende Übersicht zu bekommen, die nur über Nummern aus den Informationstabellen auslesbar ist:

1. 001 SELECT TRIM("a".RDB$RELATION_NAME) AS "Tabelle",  

2. 002    "a".RDB$FIELD_NAME AS "Feld",  

3. 003    TRIM(CASE "b".RDB$FIELD_TYPE||'|'|| COALESCE("b".RDB$FIELD_SUB_TYPE,0) 

4. 004       WHEN '7|0' THEN 'SMALLINT'  

5. 005       WHEN '8|0' THEN 'INTEGER'  

6. 006       WHEN '8|1' THEN 'NUMERIC'  

7. 007       WHEN '8|2' THEN 'DECIMAL'  

8. 008       WHEN '10|0' THEN 'FLOAT'  

9. 009       WHEN '12|0' THEN 'DATE'  

10. 010       WHEN '13|0' THEN 'TIME'  

11. 011       WHEN '14|0' THEN 'CHAR'  

12. 012       WHEN '16|0' THEN 'BIGINT'  

13. 013       WHEN '27|0' THEN 'DOUBLE PRECISION'   

14. 014       WHEN '35|0' THEN 'TIMESTAMP'  

15. 015       WHEN '37|0' THEN 'VARCHAR'  

16. 016       WHEN '261|0' THEN 'BLOB'  

17. 017       WHEN '261|1' THEN 'BLOB Text'  

18. 018       WHEN '261|2' THEN 'BLOB BLR'  

19. 019       WHEN '261|3' THEN 'BLOB ACL' 

20. 020       END) AS "SQL_Datentyp", 

21. 021    COALESCE( 

22. 022       "b".RDB$CHARACTER_LENGTH, 

23. 023       "b".RDB$FIELD_PRECISION||','|| 

24. 024       ("b".RDB$FIELD_SCALE*-1)) AS "Laenge,Nachkommastellen" 

25. 025 FROM RDB$RELATION_FIELDS AS "a", RDB$FIELDS AS "b" 

26. 026 WHERE "a".RDB$FIELD_SOURCE = "b".RDB$FIELD_NAME 

27. 027    AND "a".RDB$SYSTEM_FLAG = 0 

Diese Abfrage gibt alle genutzten Tabellen mit den Feldnamen, den Feldtypen und der Feldlänge bzw. Genauigkeit bei Dezimalzahlen an.

Die Ausgabe in dieser Abfrage erfolgt in festen Spaltenbreiten. Von der HSQLDB ist es eher so, dass nur die Anzahl der lesbaren Zeichen wiedergegeben werden. Falls also eine Ausgabe nach den Bezeichnern ausgewertet werden soll, so sind die Leerzeichen durch TRIM zu entfernen.

Automatisch generierte Werte wie in der HSQLDB werden bei Firebird über Generatoren erstellt. Um den Startwert eines solchen Generators neu einstellen zu können ist der Name des Generators erforderlich. Die folgende Abfrage liefert den Generatornamen für alle Tabellen, die von dem Nutzer erstellt wurden:

1. 001 SELECT RDB$FIELD_NAME, RDB$RELATION_NAME, RDB$GENERATOR_NAME  

2. 002 FROM RDB$RELATION_FIELDS  

3. 003 WHERE RDB$GENERATOR_NAME IS NOT NULL 

Ansichten werden auch von Firebird unterstützt. Die folgende Abfrage liefert den Namen und die SQL-Formulierung für jede Ansicht:

1. 001 SELECT RDB$RELATION_NAME, RDB$VIEW_SOURCE  

2. 002 FROM RDB$RELATIONS  

3. 003 WHERE RDB$VIEW_SOURCE IS NOT NULL 

Die Firebird-Systemtabellen starten alle mit den Anfangsbuchstaben RDB$:

1. RDB$BACKUP_HISTORY

   RDB$CHARACTER_SETS

   RDB$CHECK_CONSTRAINTS

   RDB$COLLATIONS

   RDB$DATABASE

   RDB$DEPENDENCIES

   RDB$EXCEPTIONS

   RDB$FIELDS

   RDB$FIELD_DIMENSIONS

   RDB$FILES

   RDB$FILTERS

   RDB$FORMATS

   RDB$FUNCTIONS

   RDB$FUNCTION_ARGUMENTS

   RDB$GENERATORS

   RDB$INDICES

   RDB$INDEX_SEGMENTS

   RDB$LOG_FILES

   RDB$PAGES

   RDB$PROCEDURES

   RDB$PROCEDURE_PARAMETERS

   RDB$REF_CONSTRAINTS

   RDB$RELATIONS

   RDB$RELATION_CONSTRAINTS

   RDB$RELATION_FIELDS

   RDB$ROLES

   RDB$SECURITY_CLASSES

   RDB$TRANSACTIONS

   RDB$TRIGGERS

   RDB$TRIGGER_MESSAGES

   RDB$TYPES

   RDB$USER_PRIVILEGES

   RDB$VIEW_RELATIONS

Regelmäßige Datensicherung sollte eigentlich Grundlage für den Umgang mit dem PC sein. Sicherheitskopien sind so der einfachste Weg, auf einen halbwegs aktuellen Datenstand zurückgreifen zu können. Doch in der Praxis mangelt es eben häufig an dieser Stelle.

Formulare, Abfragen und Berichte können, sofern eine Vorversion der Datenbank gesichert wurde, über die Zwischenablage in eine neue Datenbank kopiert werden. Lässt sich allerdings, aus welchen Gründen auch immer, eine aktuelle Datenbankdatei nicht mehr öffnen, so ist das Hauptproblem: Wie komme ich (hoffentlich) an die Daten.

• Hinweis 

Bevor es an die Wiederherstellung einer Datenbank-Archivdatei geht sollte erst einmal geklärt werden, ob nicht irgendwo im System doch eine Sicherungskopie existiert, die nicht bewusst angelegt wurde.
Eine Möglichkeit ist der Backup-Pfad von LibreOffice: Extras → Optionen → LibreOffice → Pfade → Sicherungskopien gibt darüber Aufschluss. Falls dieser Pfad noch nicht existiert wurde er noch nicht genutzt.
Eine weitere Möglichkeit ist das temporäre Verzeichnis des Betriebssystems:  Extras → Optionen → LibreOffice → Pfade → Temporäre Dateien dürfte hier den richtigen Pfad angeben. Unter Linux ist dies /tmp. In diesem Pfad befinden sich Verzeichnisse, die mit lu….tmp gekennzeichnet sind, also von der Namensgebung so aussehen, als wären es Dateinamen mit der Endung «tmp». In diesen Pfaden befinden sich Dateien von LibreOffice, sofern die Dateien gerade geöffnet sind und bearbeitet werden. Wird LibreOffice normal beendet, so werden diese Pfade wieder gelöscht. Alte Pfade weisen also darauf hin, dass das Programm zu dem Zeitpunkt nicht korrekt beendet wurde. Leider haben die Dateien in diesen Pfaden nicht die ursprünglichen Namen. Unter Linux lassen sich aber Dateitypen auch mit der Endung *.tmp problemlos den Programmtypen zuordnen.

Bei plötzlichen Abstürzen des PC kann es passieren, dass geöffnete Datenbanken von LO (interne Datenbank HSQLDB) nicht mehr zu öffnen sind. Stattdessen wird beim Versuch, die Datenbank zu öffnen, nach einem entsprechenden Filter für das Format gefragt.

Das Ganze liegt daran, dass Teile der Daten der geöffneten Datenbank im Arbeitsspeicher liegen und lediglich temporär zwischengespeichert werden. Oft wird erst beim Schließen der Datei die gesamte Datenbank in die Datei zurückgeschrieben und gepackt. Lediglich Eingaben, die direkt in die Tabellen erfolgen, werden auch direkt in die Datenbankdatei gesichert. Seit LO 5.1 kann außerdem die Datenbank noch über den Button Speichern gesichert werden. Dies war vorher nicht der Fall, da der Button nicht den Zugang zu einem Untermenü anbot und deshalb inaktiv war.

Um eventuell doch noch an die Daten zu kommen, kann das folgende Verfahren hilfreich sein:

1. 1.Fertigen sie eine Kopie ihrer Datenbank für die weiteren Schritte an. 

2. 2.Versuchen Sie die Kopie mit einem Packprogramm zu öffnen. Es handelt sich bei der *.odb‑Datei um ein gepacktes Format, ein Zip-Archiv. Lässt sich die Datei so nicht direkt öffnen, so funktioniert das Ganze vielleicht auch über die Umbenennung der Endung von *.odb zu *.zip.
   Funktioniert das Öffnen nicht, so ist vermutlich von der Datenbank nichts mehr zu retten. 

3. 3.Folgende Verzeichnisse sehen Sie nach dem Öffnen einer Datenbankdatei im Packprogramm auf jeden Fall: 

1. 4.Die Datenbankdatei muss ausgepackt werden. Die entscheidenden Informationen für die Daten liegen im Unterverzeichnis «database» in den Dateien «data» und «script». 

2. 5.Gegebenenfalls empfiehlt es sich, die Datei «script» einmal anzuschauen und auf Ungereimtheiten zu überprüfen. Dieser Schritt kann aber auch erst einmal zum Testen übersprungen werden. Die «script»-Datei enthält vor allem die Beschreibung der Tabellenstruktur. 

3. 6.Gründen sie eine neue, leere Datenbankdatei und öffnen diese Datenbankdatei mit dem Packprogramm. 

4. 7.Ersetzen sie die Dateien «data» und «script» aus der neuen Datenbankdatei durch die unter «4.» entpackten Dateien. 

5. 8.Das Packprogramm muss nun geschlossen werden. War es, je nach Betriebssystem, notwendig, die Dateien vor dem Öffnen durch das Packprogramm nach *.zip umzubenennen, so ist das jetzt wieder nach *.odb zu wandeln. 

6. 9.Öffnen sie die Datenbankdatei jetzt mit LO. Sie können hoffentlich wieder auf ihre Tabellen zugreifen. 

7. 10.Wie weit sich jetzt auch Abfragen, Formulare und Berichte auf ähnliche Weise wiederherstellen lassen, bleibt dem weiteren Testen überlassen. 

Hier einige der Dateien aus der Datenbank-Archivdatei im Überblick:

mimetype

1. 004 application/vnd.oasis.opendocument.base 

Diese kleine Textdatei enthält lediglich den Hinweis, dass es sich bei der Archivdatei um eine Datenbankdatei im OpenDocument-Format handelt.

content.xml einer Datenbank ohne Inhalt

1. 005 <?xml version="1.0" encoding="UTF-8"?>
   <office:document-content
   xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math="http://www.w3.org/1998/Math/MathML"
   xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0"
   xmlns:ooo="http://openoffice.org/2004/office"
   xmlns:ooow="http://openoffice.org/2004/writer"
   xmlns:oooc="http://openoffice.org/2004/calc"
   xmlns:dom="http://www.w3.org/2001/xml-events"
   xmlns:db="urn:oasis:names:tc:opendocument:xmlns:database:1.0" xmlns:xforms="http://www.w3.org/2002/xforms"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:rpt="http://openoffice.org/2005/report"
   xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" xmlns:xhtml="http://www.w3.org/1999/xhtml"
   xmlns:grddl="http://www.w3.org/2003/g/data-view#"
   xmlns:tableooo="http://openoffice.org/2009/table"
   xmlns:drawooo="http://openoffice.org/2010/draw"
   xmlns:calcext="urn:org:documentfoundation:names:experimental:calc:xmlns:calcext:1.0"
   xmlns:field="urn:openoffice:names:experimental:ooo-ms-interop:xmlns:field:1.0" xmlns:formx="urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:1.0" xmlns:css3t="http://www.w3.org/TR/css3-text/"
   office:version="1.2">
     <office:scripts/>
     <office:font-face-decls/>
     <office:automatic-styles/>
     <office:body>
        <office:database>
           <db:data-source>
              <db:connection-data>
                 <db:connection-resource xlink:href="sdbc:embedded:hsqldb"/>
                 <db:login db:is-password-required="false"/>
              </db:connection-data>
              <db:driver-settings
                 db:system-driver-settings=""
                 db:base-dn=""
                 db:parameter-name-substitution="false"/>
              <db:application-connection-settings
                 db:is-table-name-length-limited="false"
                 db:append-table-alias-name="false"
                 db:max-row-count="100">
                 <db:table-filter>
                    <db:table-include-filter>
                       <db:table-filter-pattern>%</db:table-filter-pattern>
                    </db:table-include-filter>
                 </db:table-filter>
              </db:application-connection-settings>
           </db:data-source>
        </office:database>
     </office:body>
   </office:document-content> 

Wenn, wie auf den folgenden Seiten beschrieben, die externe HSQLDB verwendet wird, kann eventuell ein weiteres Problem mit den *.odb-Dateien in Verbindung mit manchen LO-Versionen auftauchen. Wird eine externe HSQLDB genutzt, so ist der sicherste Weg der über das hsqldb.jar-Archiv, das mit LO mitgeliefert wird. Wird ein anderes Archiv verwendet, so kann das dazu führen, dass die internen Datenbanken plötzlich nicht mehr zugänglich sind. Dies liegt daran, dass LO Schwierigkeiten hat, zwischen interner und externer HSQLDB zu unterscheiden und Meldungen von einem Versionskonflikt produziert.

Es muss als externe Datenbank die mitgelieferte hsqldb.jar-Datei genutzt werden. Außerdem muss aus der *.odb-Datei das database-Verzeichnis extrahiert werden. Die Datei properties hat hier einen Eintrag, der in LO 3.3 zu dieser Fehlermeldung führt:

1. 010 version=1.8.1 

steht in Zeile 11.

Diese Zeile ist zu ändern auf

1. 010 version=1.8.0 

Danach ist das database-Verzeichnis wieder in das *.odb-Päckchen einzulesen und die interne Datenbank lässt sich auch wieder unter LO öffnen.

Wenn aus irgendwelchen Gründen wohl die Datenbankdatei geöffnet wird, aber kein Zugang mehr zu den Tabellen existiert, kann direkt über Extras → SQL der Befehl SHUTDOWN SCRIPT eingegeben werden. Anschließend wird die Datenbank geschlossen und neu gestartet. Das Ganze funktioniert aber nicht, wenn bereits ein «Error im Script-file» gemeldet wird.

Die Daten der Datenbank liegen in der *.odb-Datei im Unterverzeichnis «database». Hier gibt es eine Datei «data» und eine Datei «backup». Ist die Datei «data» defekt, so kann sie über die Datei «backup» wiederhergestellt werden. Hierzu muss die im Verzeichnis «database» liegende Datei «properties» bearbeitet werden. Hier gibt es eine Zeile «modified=no». Diese muss umgeschrieben werden zu «modified=yes». Das zeigt dem System an, dass die Datenbank nicht korrekt beendet wurde. Jetzt wird aus der komprimierten «backup»-Datei beim Neustart eine neue «data»-Datei erstellt.

Die interne HSQLDB unterscheidet sich erst einmal nicht von der externen Variante. Wenn, wie im Folgenden beschrieben, erst einmal nur der Zugriff auf die Datenbank nach außerhalb gelegt werden soll, dann ist keine Serverfunktion erforderlich. Hier reicht schlicht das Archiv, was in LO mitgeliefert wurde. Es liegt im LO-Pfad unter /program/classes/hsqldb.jar. Die Verwendung dieses Archivs ist die sicherste Variante, da dann keine Versionsprobleme auftauchen.

Die Einbindung der externen Datei hsqldb.jar in den Class-Pfad kann bei unterschiedlichen Versionen dazu führen, dass interne Datenbanken anschließend nicht mehr zu öffnen sind. Base kommt mit den gleichlautenden Treibern nicht zurecht und will die externe Variante auch für die internen Datenbanken nutzen. Das geht beim ersten Öffnen noch gut. Beim zweiten Öffnen kommt dann aber die Meldung, dass die Datenbank nicht mehr zu öffnen ist, da sie mit einer neueren Version der HSQLDB geschrieben wurde.

Die interne HSQL-Datenbank hat den Nachteil, dass die Abspeicherung der Daten innerhalb eines gepackten Archivs erfolgt. Erst mit dem Packen werden alle Daten festgeschrieben. Dies kann leichter zu Datenverlust führen als es bei der Arbeit mit einer externen Datenbank der Fall ist. Im folgenden werden die Schritte gezeigt, die notwendig sind, um den Umstieg einer bestehenden Datenbank vom *.odb-Päckchen zur externen Version in HSQL zu erreichen.

Aus einer Kopie der bestehenden Datenbank wird das Verzeichnis «database» extrahiert. Der Inhalt wird in das oben beschriebene frei wählbare Verzeichnis kopiert. Dabei sind die enthaltenen Dateien um den Datenbanknamen zu ergänzen:

1. Datenbankname.backup

   Datenbankname.data

   Datenbankname.properties

   Datenbankname.script

   Datenbankname.log

Jetzt muss noch die «content.xml» aus dem *.odb-Päckchen extrahiert werden. Hier sind mit einem einfachen Texteditor die folgenden Inhalte zu suchen, die leider in einer durchlaufenden Zeile stehen, es sei denn, man verwendet für diese Arbeit einen speziellen sog. XML-Editor:

1. 001 <db:connection-data> 

2. 002    <db:connection-resource xlink:href="sdbc:embedded:hsqldb"/> 

3. 003    <db:login db:is-password-required="false"/> 

4. 004 </db:connection-data> 

5. 005 <db:driver-settings  

6. 006    db:system-driver-settings=""  

7. 007    db:base-dn=""  

8. 008    db:parameter-name-substitution="false"/> 

Diese Zeilen sind mit der Verbindung zur externen Datenbank zu ersetzen, hier der Verbindung zu einer Datenbank mit dem Namen "medien", die jetzt im Verzeichnis «hsqldb_data» liegt.

1. 001 <db:connection-data> 

2. 002    <db:connection-resource  

3. 003       xlink:href="jdbc:hsqldb:file:/home/robby/Dokumente/Datenbanken/hsqldb_data/ 

4. 004       medien;default_schema=true;shutdown=true"/> 

5. 005    <db:login db:user-name="sa" db:is-password-required="false"/> 

6. 006 </db:connection-data> 

7. 007 <db:driver-settings  

8. 008    db:java-driver-class="org.hsqldb.jdbcDriver"/> 

Falls, wie oben geschrieben, die Grundkonfiguration der HSQLDB nicht angetastet wurde, stimmt auch der Nutzername und die nicht erforderliche Passworteinstellung.

Nach Änderung des Codes muss die content.xml wieder in das *.odb-Päckchen eingepackt werden. Das Verzeichnis «database» ist in dem Päckchen jetzt überflüssig. Die Daten werden in Zukunft durch die externe Datenbank zur Verfügung gestellt.

Für die Mehrbenutzerfunktion muss die HSQLDB über einen Server zur Verfügung gestellt werden. Wie die Installation des Servers erfolgt, ist je nach Betriebssystem unterschiedlich. Für OpenSuSE war nur ein entsprechendes Paket herunter zu laden und der Server zentral über YAST zu starten (Runlevel-Einstellungen). Nutzer anderer Betriebssysteme und Linux-Varianten finden sicher geeignete Hinweise im Netz.

Im Heimatverzeichnis des Servers, unter SuSE /var/lib/hsqldb, befinden sich unter anderem ein Verzeichnis «data», in dem die Datenbank abzulegen ist, und eine Datei «server.properties», die den Zugang zu den (eventuell also auch mehreren) Datenbanken in diesem Verzeichnis regelt.

Die folgenden Zeilen geben den kompletten Inhalt dieser Datei auf dem Rechner wieder. Es wird darin der Zugang zu 2 Datenbanken geregelt, nämlich der ursprünglichen Standard‑Datenbank (die als neue Datenbank genutzt werden kann) als auch der Datenbank, die aus der *.odb‑Datei extrahiert wurde.

1. 001 # Hsqldb Server cfg file. 

2. 002 # See the Advanced Topics chapter of the Hsqldb User Guide. 

3. 003  

4. 004 server.database.0   file:data/db0 

5. 005 server.dbname.0     firstdb 

6. 006 server.urlid.0      db0-url 

7. 007  

8. 008 server.database.1   file:data/medien 

9. 009 server.dbname.1     medien 

10. 010 server.urlid.1      medien-url 

11. 011  

12. 012 server.silent       true 

13. 013 server.trace        false 

14. 014  

15. 015 server.port         9001 

16. 016 server.no_system_exit         true 

Die Datenbank 0 wird mit dem Namen "firstdb" angesprochen, obwohl die einzelnen Dateien in dem Verzeichnis data mit "db0" beginnen. Die neue Datenbank wird als "Datenbank 1" hinzugefügt. Hier sind Datenbankname und Dateibeginn identisch.

Die beiden Datenbanken werden mit folgenden Zugängen angesprochen:

1. 001 jdbc:hsqldb:hsql://localhost/firstdb;default_schema=true
   username sa
   password 

2. 001 jdbc:hsqldb:hsql://localhost/medien;default_schema=true
   username sa
   password 

Die URL wurde hier bereits jeweils um den für den Schreibzugang über die grafische Benutzeroberfläche von LO erforderlichen Zusatz «;default_schema=true» ergänzt.

Wenn tatsächlich im Serverbetrieb gearbeitet werden soll, ist natürlich aus Sicherheitsgründen zu überlegen, ob die Datenbank nicht mit einem Passwort geschützt werden soll.

Nun erfolgt die Serververbindung über LO. Im Hauptfenster von Base wird Bearbeiten → Datenbank → Eigenschaften aufgesucht.