base 7.1.4.2 speichert nicht

Deutsch
,
#1

Ich habe eine Datenbank, mit der ich seit ein paar Jahren arbeite. Sie liegt auf einm NAS und ich bin der Besitzer der Datei. Am 31.3.2021 funktionierte noch alles. Danach habe ich LO upgedatet (vielleicht inzwischen noch einmal).
Als ich sie heute öffnete und einen Wert in einem Datensatz geändert habe, kam beim Schließen des Formulares keine Frage ob gespeichert werden soll. Die Änderung wurde auch nicht gespeichert. Beim Öffnen wird ein lock-file …lck angelegt.

Beim zweiten Versuch einer Änderung habe ich im Formular das Datei-Manü geöffnet und auf “Speichern” geklickt, die Datei wurde aber nicht gespeichert. Beim Schließen des Formulars kam jetzt aber die Frage ob die Änderungen gespeichert werden sollten. Nach einem Klick auf “Ja” wurde aber trotzdem nicht gespeichert. Auch beim Schließen von base wird nicht gespeichert.

Jetzt habe ich auch noch versucht die Datei in mein home zu kopieren, und siehe da, jetzt funktioniert es wieder. Ich kann aber eine neue DB auf dem NAS (im selben Verzeichnis wie die besprochene DB) speichern. An den Rechten auf dem NAS kann es also eigentlich nicht liegen. Das NAS ist via cifs gemountet.

Mein PC läuft mit Linux Mint 19.3.
Habt ihr eine Idee, woran das liegen kann?
LG, Karl

#2

Schau mal, ob nach (!!!) dem vollständigen Schließen von LibreOffice für die besagte Datei, die Du nicht mehr speichern kannst, eine .~lock.<dateiname># auf dem NAS liegen geblieben ist (exakt so, nicht verwechseln mit etwas, was auf .lck endet). Wenn dem so ist, wird Deine Datei immer im Nur-Lesemodus, also ohne Schreibberechtigung, geöffnet. Lösche diese Datei (bei geschlossenem LibreOffice) und starte LibreOffice mir der Base Datenbank wieder.

#16

Vergiss doch einfach die eingebettete HSQLDB und verwende eine externe HSQLDB.

  1. Kopiere dein Base-Dokument in ein neues lokales Verzeichnis.
  2. Erstelle ein Unterverzeichnis “driver” in diesem Verzeichnis.
  3. Lade HSQL 2.4.1 herunter und extrahiere /lib/hsqldb.jar in das Verzeichnis “driver”.
  4. Lade mein Installer-Dokument https://forum.openoffice.org/en/forum/download/file.php?id=35569 herunter und klicke den Knopf.
  5. Öffne das Base-Dokument und rufe auf:
    Extras>Macros>Ausführen>“Meine Macros”>pyDBA>ExtractHSQLDB>Main
    Die Statuszeile des Dokuments zeigt jetzt jdbc:hsqldb:file:/pfad/database/Datenbankname;…
  6. Teste das Dokument, ob alle Formulare und Berichte noch laufen.
  7. Schließe das ganze und verschiebe den Datenbankordner auf das NAS.
  8. Menü:Bearbeiten>Datenbank>EIgenschaften… und ändere den Dateipfad in der URL zwischen file: und dem Semikolon.

Jetzt hast Du immer noch eine Desktop-Datenbank für einen einzelnen Benutzer, aber wenigstens hast Du das Backend und das Frontend voneinander getrennt, was wesentlich sicherer ist. Lasse das Datenbankdokument auf dem Rechner und greife damit auf die eigentliche Datenbank auf dem NAS zu.
Wenn alles funktioniert kannst Du die eingebettete Datenbank aus dem Base-Dokument entfernen. Die ist immer noch drin aber wird nicht mehr benutzt.
Extras>Macros>Ausführen>“Meine Macros”>pyDBA>ExtractHSQLDB>Revert_To_Embedded aktiviert wieder die eingebettete Datenbank
Extras>Macros>Ausführen>“Meine Macros”>pyDBA>ExtractHSQLDB>Remove_Embedded löscht die eingebettete Datenbank.

#3

Folgende Probleme sind bekannt:

Externe Formulare haben bis von der Version 5.1 zur Version 6.3.5 von LO keine richtige Speicherung durchgeführt. Die Speicherung fand erst dann statt, wenn die Datenbank selbst geöffnet und geschlossen wurde.

Die Nutzung von externen Formularen kann in Zusammenhang mit FIREBIRD zu Datenverlusten führen. Die Firebird Datenbank benötigt auch in LO 7.1 immer noch die Sicherung der Daten über das Speicher-Symbol der Datenbankdatei.
Nur mittels Makro kann diese Sicherung auch bei externen Formularen erfolgen. Dabei sollte das Makro an die Eigenschaft “Nach der Datensatzaktion” gebunden werden:

SUB DataSave(oEvent AS OBJECT)
oEvent.Source.activeConnection.Parent.flush
END SUB

Versuchst Du auf die Datenbank direkt zuzugreifen, das heißt öffnest Du die Datenbankdatei und greifst nicht über ein externes Formular zu, so ist eine Änderung von der Buglage her mir nicht bekannt. Das Speichern eines Formulars hilft da auch überhaupt nichts. Das ist nämlich lediglich für das Speichern des Formulardesigns gedacht. Das Speichern der Daten geschieht eben über die Nachfrage beim vorzeitigen Schließen (ohne Datensatzwechsel) oder bei Firebird beim Schließen der Base-Datei.

#4

Erst mal danke an Opaque und RobertG.

Zur Klarstellung: Wenn ich die Datei, die bis April 2021 funktioniert hat, öffne, wir bei der ersten Aktion (z.B. Anklicken von “Tabellen” die lock-Datei erzeugt. Egal ob ich direkt in die Tabelle schreibe/ändere oder in einem Formular, die Datei wird nicht gespeichert. Die lock-Datei wird aber wieder entfernt, sobald ich die Datenbank (nicht das Formular) schließe. Sieht also völlig normal aus, ist es aber nicht. Diese Datei hat den Namen daten/NAS-Archiv/Kd-backup/Video/video_test.odb .

Wenn ich die Datei in home/karls/temp/video_test.odb kopiere funktioniert es.

Eine calc-Datei läßt sich am ursprünglichen Ort aber erzeugen. Beim Anlegen einer neuen Datenbank kommt beim Schlließen des Programms zwar die Frage nach “speichern vor beenden”, aber nach Klick auf “Speichern” wird das Programm nicht beendet. Erst bei “schließen ohne speichern” beendet sich das Programm. Die Datenbank-Datei existiert dann zwar, ist aber leer. Auf dem gesamten Pfad sind Benutzer und Gruppe gleich und writer und calc funktionieren ohne Probleme.

Hat jemand von euch einen Tipp wie ich dieses Problem lösen könnte bzw. dien grund herausfinde.
LG, Karl

PS: Ich verwende die “eingebettete HSQLDB”.

#5

Wenn schon das Speichern beim Erstellen einer neuen Datei nicht funktioniert, sehr wohl aber mit Writer und Calc funktioniert, dann tippe ich auf ein Java-Problem. Ich habe allerdings noch nie eine Datenbank auf einem NAS von der Ferne bedient - habe gar kein NAS. Vielleicht kommst Du dem Problem etwas auf die Schliche, wenn Du Libreoffice von der Konsole aus startest. Dann tauchen auch die möglichen Fehlermeldungen auf, die zum Beispiel das Abspeichern einer neuen Base-Datei unmöglich machen. Also die Konsole einmal in /opt/libreoffice7.1/program öffnen und dort ./soffice ausführen. Dann noch einmal eine Datenbankdatei versuchen zu erstellen. Erscheint irgendetwas beim Abbruch?

#6

Hi Robert,
gute Idee! Beim Anlegen einer DB kommt die Fehlermeldung

GTK-WARNING ** 15:10:21.973: Failed to set property AtkObject.accessible-role to static: Could not parse integer ‘static’

beim Speichern der DB-Datei. Wenn ich dann eine Tabelle anlege kommt bei der Eingabe eines Feldnamens und auswahl eines Typs mehrere weitere Fehlermeldungen:

…WARNING **: 15:11:21.506: Focused object has invalid index in parent

Das hängt wahrscheinlich vom ersten Fehler ab.

Natürlich habe ich auch gegooglet, aber nichts gefunden was mir hilft.

Wenn ich eine DB in meinem home anlege, kommen die gleichen Meldungen, aber die Datei wird gespeichert! ???

Jetzt bin ich noch ratloser.

Ich verwende einen PC mit Intel i7, 64bit, Linux Mint19.3

#7

Es kommt also keine Meldung, die sich irgendwie auf Java bezieht? Was für Versionen hast Du denn installiert. Ist es vielleicht möglich, dass aus dem NAS auch eine Java-Version läuft, die aber unterschiedlich zu der Version ist, die auf Deinem Rechner läuft? Könntest Du versuchen, diese Version vom NAS über Extras → Optionen → Erweitert in LO mit einzubinden? Wie geschrieben: Mit NAS habe ich sonst nichts zu tun und Java ist der Hauptunterschied zu den anderen Programmmodulen - vor allem bei einer Nutzung der HSQLDB.

Mit SAL_USE_VCLPLUGIN=gen ./soffice hast Du nicht die ganzen gtk-Fehlermeldungen. Habe ich gerade einmal durch getestet. Da kommt bei mir nichts auf der Konsole.

#8

Nein, nix zu java. Ich habe mehrere Versionen installiert (lt. Extras | Optionen | Erweitert):

Oracle Corporation 13.0.1

Ubuntu 11.0.11

Oracle Corporation 1.8.0_231 diese verwende ich mit LO

Das NAS ist ein QNAP und es scheint kein java drauf zu sein. Es würde mich aber wundern, wenn darin die Ursache läge, da das NAS als cifs-Dateisystem eingebunden ist und ja mit der Programmausführung nichts zu tun hat.

Kommende Woche werde ich noch mit anderen Coputern versuchen wie es läuft.

#9

Vielleicht ist das Bug 140484. Ich weiß nicht, warum sich bei dem Bug nichts tut, obwohl die Person, die ihn gemeldet hat, selbst Entwickler gerade im Bereich Base ist …

Welche Version von LO hattest Du denn vor dem 31.3.21 installiert? Vielleicht kannst Du die einfach wieder drauf packen.

#10

Hi, jetzt habe ich mal an anderen PCs probiert:

Win10 32-bit, LO 7.1.1.2(x86) mit jre Oracle 8u301 …DB auf NAS bearbeiten funktioniert

Linux Mint20, LO 6.4.7.2 mit jre Ubuntu11.0.11 …DB auf NAS bearbeiten funktioniert

nur auf meinem Arbeitsplatz Linux Mint 19.3, LO 7.1.4.2 mit jre Oracle 1.8.0_231 …DB auf NAS bearbeiten funktioniert NICHT! Nur wenn ich eine lokale Kopie anlege, kann ich die DB bearbeiten. Welche LO-Version vorher darauf war weis ich nicht mehr. Da das derzeit mein einziges Problem ist, will ich nicht downgraden. Danke trotzdem für deine Bemühungen.

#11

Ich habe das gleiche Problem. Alle Komponenten außer Base funktionieren einwandfrei mit Dateien auf dem NAS (Synology SDS 215j). Das Netzlaufwerk ist eingebunden über mount cifs im Ordner “NAS” des aktuellen Users. Libre Office ist Version 7.3.6.2, Betriebssystem Linux Mint 21. Unter LM 19 mit älterem Libre Office funktionierte es.

#12

Bei Linuxversionen am besten immer die Build-ID mit angeben, damit klar ist, ob es sich um eine Distributionsversion oder die direkt von LibreOffice handelt. Und wenn das Verhalten bei einer Version direkt von LibreOffice vorkommt: Bitte im Bugtracker melden: https://bugs.documentfoundation.org/

#13

Hallo Leute,
ich habe LO nun upgedatet auf Version 7.4.2.3
build Log - 382eef1f22670f7f4118c8c2dd222ec7ad009daf - core - Gitiles

Ds Problem ist noch immer da :-(( Kann das denn sein, dass das so lange nicht behoben wird? Das funktionierte doch früher schon mal (ich denke in einer 5er oder 6er Version.
Wer einen Tipp für mich hat - bitte melden!
TIA, Karl

#14

Wo hast Du denn den Bug dazu gemeldet? Der, den ich oben in einem Beitrag genannt hatte, ist inzwischen geschlossen, da nicht genügend Informationen dazu vorliegen, dass der Bug überhaupt bei anderen auch auftritt.
Da es nur Base betrifft würde ich einmal etwas testen:
Experimentellen Modus ein - Firebird Datenbank als interne Datenbank erstellen.
Experimentellen Modus wieder aus, damit nicht der Migrationsassistent bei HSQLDB-.Datenbanken auftaucht.
Firebird Datenbank auf das NAS legen und dann darauf zu greifen.
Klappt das, dann liegt der ganze Schlamassel nicht an LO und Base sondern an der Kombination Base/Java. Da muss dann gegebenenfalls eine andere Java-Version her.

#15

Allein in diesem Thread findest Du ein buntes Durcheinander von Versionen und Distros - mal funktioniert es, mal nicht.
Das macht eine Fehleranalyse schwierig.
.
Meist nicht einmal erwähnt sind die Netzwer-Parameter:

  • Samba-Version von Rechner und NAS
  • cifs extensions
  • wie gemounted - /etc/fstab oder mit einem automount und entsprechend mit welchen parametern
  • gio bzw kio zur Einbindung …

Alle diese Dinge können sich bei einem Wechsel der distribution oder auch dist-upgrade oder gar Neuinstallation ändern.

Und solange die Ursache im Nebel bleibt ist ein bugfix ziemlich schwierig.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.