[gelöst] Base abgestürzt, kein Datenbankzugriff mehr

[Pit Zyclade]

Ich bin mir keines Verhaltensfehlers bewußt, aber nach Einträgen in mehrer Datensätze einer Abfrage, die auf einer Tabelle von vieren einer internen DB beruht, wollte LO nicht mehr. Mußte ich also abschießen. Auch nach Computerneuanfang und LO-Datenwiederherstellung komme ich nicht mehr an meine Tabellen ran. Ich erhalte die angehängte Nachricht. Bedauerlich, weil ich schon viel Arbeit reingesteckt hatte.

Was tun?

Nach Datenbankabsturz

Datenbankabsturz.jpg (16.32 KiB) 2910 mal betrachtet

Danke für Hilfe

[Freischreiber]

Hallo Pit,

die interne DB ist etwas anfällig.
Reparaturhinweise gibt es in Roberts Handbuch:

http://robert.familiegrosskopf.de/lo_hb ... db-Dateien

Hab ich noch nie probiert, weil ich zuerst Glück hatte und dann auf eine externe DB umgestiegen bin (interne DB gesplittet).

Gruß und viel Glück
Freischreiber

[Pit Zyclade]

Das Verfahren "Wiederherstellung" funktioniert nicht so wie beschrieben.
1. Während das Auspacken mit 7zip problemlos erscheint, fällt schon im Beispielbild auf, dass dort keine Datei "data" vorhanden ist.
2. Eine "neue leere DB" wie genannt hat (in V 4.4.7.2 jedenfalls) noch keine Tabelle, also auch kein Verzeichnis "database"
3. Alternativ kann man eine neue DB, die "bearbeitbar" sei, anlegen. Diese verfügt dann schon über "database", daber enthalten sind in ihm nur "script" und "properties".
4. Schafft man eine neue DB mit wenigstens einer Tabelle, so sind die betreffenden Dateien ("data" und "script") vorhanden, können also ausgetauscht werden.

Speziell in meinem Falle aber wurde so nur die Tabellenstruktur aller 4 Tabellen (zumindest die Spaltennamen) wiederhergestellt, aber die Daten selbst waren leider im Nirwana. Die zwei Abfragen waren ebenfalls, wie erwartet, fort, Formulare hatte ich noch keine angelegt. Dennoch ist so alle Arbeit zerronnen. Man lernt eben nie aus.

[Freischreiber]

Hallo Pit,

das ist natürlich schlecht. Ich bin aber auch nicht sicher, ob dein Absturz nicht etwas anderes war als das, was Robert beschreibt. Deine Fehlermeldung sieht anders aus als die Frage nach dem Formatfilter.

Wenn du mit der Datenbank wichtige Daten verwalten willst, kommst du auf Dauer um eine gesplittete DB nicht herum. Ich habe es damals nach dieser Beschreibung gemacht:
https://forum.openoffice.org/en/forum/v ... 83&t=61183

Es ist einmal Arbeit, danach will man eigentlich nie mehr zurück. Einziger Nachteil ist, daß man Änderungen an der DB-Struktur (Tabellen erstellen und verändern) fast nur noch mit SQL-Befehlen durchführen kann (geht aber mit Einarbeitung auch). Am wenigsten Arbeit hat man, wenn man eine in der Struktur fertige DB splittet, wo man an den Tabellen nichts mehr ändern muß.

Hier noch ein Sicherheitshinweis: http://www.libreoffice-forum.de/viewtop ... 77&p=37739

Seither hatte ich manchmal Abstürze von Base beim Arbeiten an Formularen oder Abfragen, aber nach Neustart ging die DB immer wieder auf, und es waren nie Daten weg.

Gruß
Freischreiber

[Freischreiber]

Hier: http://de.openoffice.info/viewtopic.php?t=67122
hatte schon mal jemand dein Problem...

Schnellstarter ausschalten (siehe ganz unten) bzw. gar nicht erst installieren in LO ist auf jeden Fall wichtig. Und eben Datensicherungen.

[RobertG]

Hallo *,

die Treiberklasse zu einer internen Datenbank müsste in der content.xml der *.odb-Datei durch die folgenden Zeilen vordefiniert sein:

Code: Alles auswählen

<db:connection-data>
<db:connection-resource xlink:href="sdbc:embedded:hsqldb"/>
<db:login db:is-password-required="false"/>
</db:connection-data>

In den anschließenden Zeilen steht dann

Code: Alles auswählen

<db:driver-settings
db:system-driver-settings=""

... und da liegt wohl die Fehlermeldung begründet.

Ebenfalls in content.xml liegen die Abfragen. hier wieder aus dem Handbuch:

Code: Alles auswählen

<db:queries>
<db:query
db:name="Verkauf_berechnet"
db:command="SELECT "a".*, ( SELECT "Preis" * "a"."Anzahl" FROM "Ware" WHERE
"ID" = "a"."Ware_ID" ) AS "Anzahl*Preis" FROM "Verkauf" AS "a""/>
</db:queries>

Fehlende Abfragen können also nicht durch eine neue Datenbank einfach so wiederhergestellt werden. Sie werden, im Gegensatz zu Ansichten, nicht in der Datenbank gespeichert.
Außerdem gilt noch der folgende Abschnitt des Handbuches:

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.

Gruß

Robert

[Pit Zyclade]

die Treiberklasse zu einer internen Datenbank müsste in der content.xml der *.odb-Datei durch die folgenden Zeilen vordefiniert sein:

Code: Alles auswählen

<db:connection-data>
<db:connection-resource xlink:href="sdbc:embedded:hsqldb"/>
<db:login db:is-password-required="false"/>
</db:connection-data>

In den anschließenden Zeilen steht dann

Code: Alles auswählen

<db:driver-settings
db:system-driver-settings=""

... und da liegt wohl die Fehlermeldung begründet.

Eben nicht. Die Zeilen in der "unverändert kranken" DB sind bei mir identisch.

Außerdem gilt noch der folgende Abschnitt des Handbuches:

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.

Und hier klickte es bei mir im Kopf. Denn in meiner DB stand «modified=yes», aber die backup war nur 12 kB groß, die data hingegen 39 kB. Also hab ich das Gegenteil gemacht und in «modified=no» geändert und wieder eingezipt. Siehe da, die DB läßt sich öffnen und scheint alle Datensätze noch zu enthalten.

Einzig komisch, während ich diese Zeile schreibe und in meinem win7pro-Multitasking die DB offen ließ, schläft die DB genauso wie vormals ein (kreisender Ring, Fenster-Bild wird schwach und oben am Fensterrahmen steht "keine Rückmeldung"). Nicht vertrauenserweckend.
Ich kann sie abschießen, dann automatisch LO-wiederherstellen lassen und alles ist wieder da. Dennoch würde ich mich freuen, wenn irgendwann das DB-Verhalten nicht sooo anspruchsvoll kritisch wäre.

Aber Dank an alle und speziell an Robert für die tief schürfende Erklärung (denn ich bin auf diesem Gebiet Laie)