HSQLDB Datenbank defekt

de-users
#1

Guten Morgen Liste,

ich hab folgendes kleines Problem:
Windows 7 / LO 3.6.3
Wir haben eine Datenbank mit Werkzeugen (+Bild/Werkzeug).
Die hat es wohl infolge eines Hardwarefehlers zerlegt.
Die Datenbank wird von LO nicht mehr erkannt, wenn ich die ODB mit einem ZIP-Programm öffne wird ein Fehler der ZIP-Struktur gemeldet, die Datei aber geöffnet.
Nun hab ich die Datei mit ZIP-Repair "behandelt" ohne Erfolg.
Dann habe ich eine neue Datenbank angelegt und die Verzeichnisse eins ums andere in die neue DB kopiert.
Die Tabellen sind schon mal hergestellt, nur die Formulare werden nicht angezeigt (der Bereich "Formulare" ist leer. Welche Datei ist für die Anzeige der Formulare zuständig?

#2

Hallo Edgar,

Die Tabellen sind schon mal hergestellt, nur die Formulare werden nicht
angezeigt (der Bereich "Formulare" ist leer. Welche Datei ist für die
Anzeige der Formulare zuständig?

Es muss ein Unterverzeichnis "forms" geben. In diesem sind je nach
Anzahl der Formulare Unterverzeichnisse Obj...

Diese Formulare müssen in der Datei content.xml verzeichnet sein, die
auf der höchsten Ebene liegt:
<db:forms>
<db:component db:name="Formular1" xlink:href="forms/Obj12"
db:as-template="false"/>
<db:component db:name="Formular2" xlink:href="forms/Obj22"
db:as-template="false"/>
</db:forms>

... eben je nach Lage der Formulare.
Nur die Formulare und Berichte werden angezeigt, die in dieser
content.xml vertreten sind. Die Abfragen werden sogar direkt darin
aufbewahrt, also nirgendwo zwischengespeichert.

Gruß

Robert

#3

Hallo Robert,

Danke für deine Antwort.

Es muss ein Unterverzeichnis "forms" geben. In diesem sind je nach
Anzahl der Formulare Unterverzeichnisse Obj...

Das Unterverzeichnis "Forms" hab ich ja komplett in die neue Datei kopiert.

Diese Formulare müssen in der Datei content.xml verzeichnet sein, die
auf der höchsten Ebene liegt:
<db:forms>
<db:component db:name="Formular1" xlink:href="forms/Obj12"
db:as-template="false"/>
<db:component db:name="Formular2" xlink:href="forms/Obj22"
db:as-template="false"/>
</db:forms>

Ja, Mist, genau die Datei ist in der defekten Datei komplett leer!
Der Einbau der XML-Statements in die neue erscheint mir doch etwas kompliziert, zumal ich nicht weiß auf welche Ebene das muss.
Es ist nur ein Formular und ich denke es wird einfacher das Formular neu zu bauen, war ja nicht sehr kompliziert

#4

Hallo Edgar,

Danke für deine Antwort.

Es muss ein Unterverzeichnis "forms" geben. In diesem sind je nach
Anzahl der Formulare Unterverzeichnisse Obj...

Das Unterverzeichnis "Forms" hab ich ja komplett in die neue Datei kopiert.

Diese Formulare müssen in der Datei content.xml verzeichnet sein, die
auf der höchsten Ebene liegt:
<db:forms>
<db:component db:name="Formular1" xlink:href="forms/Obj12"
db:as-template="false"/>
<db:component db:name="Formular2" xlink:href="forms/Obj22"
db:as-template="false"/>
</db:forms>

Ja, Mist, genau die Datei ist in der defekten Datei komplett leer!
Der Einbau der XML-Statements in die neue erscheint mir doch etwas
kompliziert, zumal ich nicht weiß auf welche Ebene das muss.
Es ist nur ein Formular und ich denke es wird einfacher das Formular neu
zu bauen, war ja nicht sehr kompliziert

Eigentlich darf diese Datei nicht komplett leer sein. Sie müsste auch
einen Hinweis auf die Verbindung zur internen Datenbank geben.

Das Erstellen der Datei ist vermutlich einfacher, als es aussieht. Ich
habe das nur testweise für eine Datenbank gemacht: Eine Tabelle, eine
Abfrage, ein Formular und ein Bericht - keine großen Inhalte. Dann die
Datenbank geschlossen und die entsprechende content.xml geöffnet. Damit
hatte ich dann die gesamte Struktur.

Das Blöde an den Dateien ist, dass sie eben nicht strukturiert mit
Absätzen aufgebaut sind, sondern einfach alles aneinandergereiht wird.
Für jemanden der den Code lesen will, ist das deutlich erschwerdend.

Du kannst natürlich den folgenden Weg gehen:
Gründe ein neues Formular - kann leer sein. Speichere das ab. Öffne
anschließend die Datei. Kopiere in das entsprechende Verzeichnis Obj...
des neuen Formulars den Inhalt des alten, das ja ausgearbeitet war.
Jetzt dürfte das alte Formular auch in der Datenbank verfügbar sein.

Gruß

Robert

#5

Hallo Robert,

Eigentlich darf diese Datei nicht komplett leer sein. Sie müsste auch
einen Hinweis auf die Verbindung zur internen Datenbank geben.

Der Rechner des Kollegen neigt dazu einzufrieren :frowning:
Das ist halt einmal zu oft passiert. Wenn ich die Originaldatei mit einem Zipper öffne, kommt die Meldung, das die innere Struktur defekt ist und die content.xml konnte gar nicht angezeigt werden. Nach einer
Reparatur mit ZIP-Repair war die dann leer.
Natürlich konnte die ODB überhaupt nicht mehr geöffnet werden.

Hab dann eine neue Datenbank erstellt und die database der defekten in die neue kopiert. So waren schon mal die Tabellen da.

Das Blöde an den Dateien ist, dass sie eben nicht strukturiert mit
Absätzen aufgebaut sind, sondern einfach alles aneinandergereiht wird.
Für jemanden der den Code lesen will, ist das deutlich erschwerdend.

geht aber mit einem XML-Viewer zu lesen :wink: nur beim Editieren mit einem einfachen Texteditor eindeutig mühsam.

Du kannst natürlich den folgenden Weg gehen:
Gründe ein neues Formular - kann leer sein. Speichere das ab. Öffne
anschließend die Datei. Kopiere in das entsprechende Verzeichnis Obj...
des neuen Formulars den Inhalt des alten, das ja ausgearbeitet war.
Jetzt dürfte das alte Formular auch in der Datenbank verfügbar sein.

Ja clever! Ich hab die content.xml von dem neuen Formular auf das "alte" umbiegen wollen, das ging nicht. Dein Weg hat funktioniert!
Vielen Dank für den Tipp.

BTW die Datenbank reagiert etwas langsam, da gibt es doch einen SQL-Befehl zum kompaktieren oder wirkt der nur auf die Tabellen?

#6

Hallo Edgar,

BTW die Datenbank reagiert etwas langsam, da gibt es doch einen
SQL-Befehl zum kompaktieren oder wirkt der nur auf die Tabellen?

Der wirkt auf die Datenbank selbst, in der Regel macht der den
Dateninhalt nur kleiner - beseitigt "Schrott". Das geschieht aber in der
3.6 z.B. schon automatisch.
Sonst: Im SQL-Modus "SHUTDOWN COMPACT" - danach Base schließen und
wieder öffnen.

Gruß

Robert

#7

Hallo Robert,

Der wirkt auf die Datenbank selbst, in der Regel macht der den
Dateninhalt nur kleiner - beseitigt "Schrott". Das geschieht aber in der
3.6 z.B. schon automatisch.

meinte ich auch schon mal gelesen zu haben, aber:
Der Befehl hat die Dateigröße verringert

Sonst: Im SQL-Modus "SHUTDOWN COMPACT" - danach Base schließen und
wieder öffnen.

danach reagiert die Datenbank dennoch träge.
Komischer Weise öffnet sie blitzschnell, nur das Schließen dauert.
Aber mein Kollege hat auch Bilder in der Datenbank, nicht viele, aber ich kenne die Größe nicht. Das wird es wohl ausmachen.

Egal, das Ding tut wieder und mein Part ist damit getan.
Dir vielen Dank für deiner nützlichen Tipps.

#8

Hallo Edgar,

Komischer Weise öffnet sie blitzschnell, nur das Schließen dauert.
Aber mein Kollege hat auch Bilder in der Datenbank, nicht viele, aber
ich kenne die Größe nicht. Das wird es wohl ausmachen.

Es gibt ein Problem mit der Geschwindigkeit von Datenbanken seit der
Version LO 3.5.0 rc2 (rc1 lief noch gut). Die Geschwindigkeit von
Datenbanken hat dann noch einmal zu 3.6 hin abgenommen. Dies fällt bei
besonders viel Daten auf, z.B. Tabellen mit ab 10000 Datensätzen.

Die am schnellsten laufenden Datenbanken haben eine kleinere
Versionsnummer als 3.4.6. Genauere Informationen kannst Du aus diesem
Bugreport ziehen:
https://bugs.freedesktop.org/show_bug.cgi?id=51976#c16

Ich nutze allein wegen der Datenbanken weiterhin die 3.3.4

Gruß

Robert