Mehrbenutzer Betrieb

[RobertG]

Vielleicht ist es ja einfach die Einstellung für die Autoincrement-Werte:
Bearbeiten → Datenbank → Erweiterte Einstellungen
Generierte Werte berücksichtigen anklicken
GENERATED BY DEFAULT AS IDENTITY(START WITH 0)
eintragen
und
CALL IDENTITY()
für die zurückgegebenen Werte …

[herz4]

Danke Robert. An dieser Stelle waren bei mir unverständliche Einträge, habe sie ersetzt und leider keine Besserung erreicht.

Mein Spielen mit den properties (in der Verbindungszeile) brachte auch keine Lösung ansich, aber ein wenig mehr Verständnis für deren Bedeutung.

Ich will hier nochmals deutlich schreiben, wie sich mir der - Fehler - offenbart und was dennoch geht!

Meine Server-HSQL-DB wird mit LO Base verbunden, ich kann auf Tabellen und sogar Formulare zugreifen, scrollen und ähnlich. Ich kann keine Daten editieren, keine neuen Datensätze in diesen(!) eingeben, im Menü Bearbeiten der Tabelle ist das Untermenü Daten ändern (u. a.) ausgegraut.

Über eine Base-SQL-Anfrage (Extras - SQL ...) kann ich sowohl Daten editieren, Updates abarbeiten lassen, als auch neue Datensätze einfügen lassen. Diese sind hernach auch in Tabellen und Formularen sichtbar.

(SQL-Abfragen sind in LO Base casesensitiv, direkte Abfragen nicht.)

Diese (misslichen) Effekte treten sowohl auf dem PC (LO-Version s. u.) als auch dem Laptop mit LO 7.3.7.2 auf, jeweils Linux. Unterschied zwischen beiden Versionen: Auf dem PC kann ich den hsqldb.jar-Treiber per Makro zuweisen, auf dem Laptop nicht, da muss ich ihn als zusätzliche Klasse eintragen.

Daraus schließe ich, dass die Verbindung über den Java-Treiber (prinzipiell) funzt. Die Ausgabe insbesondere von nicht editierbaren Tabellen erinnert an Views, die ihrer Natur nach nicht editierbar sind. Mir scheint, LO Base hat da einen "internen" Fehler. Auch mein Spielen mit neueren HSQLDB.jar-Treibern - auf der Clienten-Seite - war ohne jeden Erfolg.

Ich bin weiter ratlos und freute mich über jede Anregung.

P.S. Ich fand einen ersten interessanten Hinweis auf eine mögliche Herkunft meines Problems hier:
https://forum.openoffice.org/en/forum/v ... p?t=106762
(Ich habe aus Sicherheitsgründen [für Dateneingaben via Browser] auch mehrere, teilberechtigte User in der DB erklärt. Mein in LO-Base genommener Benutzer ist der System-Admin, hat uneingeschränkte Rechte. Dennoch scheint mir - momentan - dies die wahrscheinlichste Fehlerursache, weil Base auch in der User-Administration "abgespeckt" läuft.)

[RobertG]

Der Bug, der mit der hsqldb.jar auftritt, tritt aber erst mit HSQLDB 2.6 auf. Vorher lief das anscheinend problemlos. Siehe https://bugs.documentfoundation.org/sho ... ?id=146568.

Bei dem Bug fehlt auch die Bestätigung, dass das weiter so ist.

[herz4]

Guten Morgen Robert, Freischreiber, Slid24 & weiter Interessierte

seit etwa einer Stunde kann ich die Server-HSQLDB wieder in gewohnter Weise über LO-Base administrieren: mit unveränderten Java- und LO-Versionen und nur einem(!) kleinen Häkchen an der - entscheidenden - Stelle, dem Menü Bearbeiten > Datenbank > Erweiterte Einstellungen unter "Die Rechte vom Datenbanktreiber ignorieren", eine für mich bis dato unverständliche Option.

Das Ignorieren meint wohl in diesem Fall nicht, wie gemeint sein könnte, dass Lese- oder Schreibrechte nicht in Anspruch genommen sollen, sondern umgekehrt, dass deren Einschränkungen des jeweiligen Nutzers nicht - durch LO-Base - und vorerst beachtet werden. (Ich habe keinen Grund zu der Vermutung, dass umgekehrt ein in Rechten durch die HSQLDB eingeschränkter Nutzer etwa einen erweiterten oder Vollzugriff auf die DB bekommt.)

Die Krux dahinter liegt in der Rechteverwaltung durch LO Base, die sich erschließen kann im Menü Extras > Benutzerverwaltung ..., wo mir LO Base (mit ext. und Server HSQLDB) in einem Warnfenster erklärt: "Die Datenbank unterstützt keine Benutzerverwaltung.", was nur eine halbe Wahrheit sein dürfte, weil LO Base nur keine Schnittstelle zur Benutzerverwaltung der DB anbietet, vermutlich nicht besitzt. Damit könnte einher gehen, dass es auch keine Rechte ermitteln, und wenn dies auch nicht beachten kann.

Wenn denn keine Rechte auf Base's Seite bekannt sind, können sie entweder auch nicht benutzt werden, z. B. keine Schreibrechte in Anspruch genommen werden (bei fehlendem Haken) oder aber generell "vermutet" werden (Haken gesetzt). Das könnte nach meiner Erwartung zu einem Fehler führen, wenn DER Haken gesetzt ist, und der Nutzer im speziellen Fall zwar Lese-, aber keine Schreibrechte in einer Tabelle (oder auch nur einer Spalte) hat, die er dann editiert. Ich gehe (optimistischer Weise) davon aus, das der HSQLDB-Treiber davor ist, er nicht in die DB schreibt, wenn er denn bei diesem Nutzer nicht darf. Und Base qualifiziert den Fehler hoffentlich sichtbar, etwa mit: "Der Datensatz/ die Änderung konnte nicht gespeichert werden."

Eines kann ich mit Bestimmtheit bestätigen: Ohne Leserechte des Benutzers wird die betreffende Tabelle gar nicht erst angezeigt, nicht einmal ausgegraut, sie existiert für ihn nicht (sichtbar), er hat keinen Zugriff.

Noch zu meinem, oben betonten EINEN Haken. Der war es tatsächlich auch bei wenigstens zwei Geräten (Clienten), die alle - eine - odb-Datei auf dem Server nutzen. Natürlich ist dies kein HSQLDB-Server, nicht einmal ein Dateiserver meines nginx-Servers, dem ich den Vorzug vor einem Apache gegeben habe, sondern es ist der "physische" Zugriff per sftp-Protokoll auf diese eine Datei, die im Server(dateisystem) gespeichert ist. Kann es da zu Inkonsistenzen kommen? In der Datenbank selbst nicht, aber im Zugriff durch LO-Base?

Vermutlich könnte mein (nunmehr ehemaliger) Fehler etwa so provoziert worden sein. Die Benutzerverwaltung, zumindest die im Menü von LO-Base könnte eine (hier) jüngere Änderung sein, mit der auch das Häkchen, die Option: "Die Rechte vom Datenbanktreiber ignorieren", Eingang in die "Erweiterten Einstellungen" (s. o.) gefunden hat, die offensichtlich (wenigstens zum Teil) in der odb-Datei gespeichert werden.

Ich speichere diese Datei "zentral", um Weiterentwicklungen auf beiden Systemen unmittelbar zur Verfügung zu haben. Dies hat aber seine Grenzen bei fraglichen Abwärtskompatibilitäten, weshalb mutmaßlich mein Fehler also "schon" bei HSQLDB 2.5.0 und vor allem bei beiden Systemen auftrat, wobei eines noch "antiquierter" ist als das andere. Ich muss also unter diesem Blickwinkel auf eine größere "Nähe" der Versionen achten.

Ist eine solche, "zentrale" odb-Datei in wirklichen Mehrbenutzerumgebungen (über den Familienrahmen hinaus) zu empfehlen? Das kommt ganz auf den Administrator an. Man kann unter Linux(!) den Nicht-Admin-Nutzern die Schreibrechte der odb-Datei entziehen, sie so vor unautorisierter Veränderung schützen. Dann müssten sich die Nicht-Admin-Nutzer daran gewöhnen, das Speichern des odb-Datei zu verneinen, sonst bekommen sie sie nicht zu. Geht, kann man machen. Aber dann kann auch niemand individuelle Einstellungen vornehmen.

In diesem (produktiven) Fall sollte vielleicht doch einem zu updatenden Master-System der odb-Datei der Vorzug gegeben werden ...

Ich danke ganz besonders Robert, aber auch Freischreiber für Offenheit, Verständnis und die zahlreichen Anregungen, ohne die ich nicht oder zumindest nicht so schnell auf des Pudels Kern gestoßen wäre.

(Weil ich diese Hilfe zu schätzen gelernt habe, möchte ich gern das Forum materiell unterstützen. Ich habe weder Debit noch Kreditkarte, halte auch von Paypal nichts. Bitte, liebe Forum-Admins, nehmt mit mir über die Euch gegebene Mailadresse dazu Kontakt auf, ich wollte gern per Dauerauftrag anweisen.)

Mit herz4lichen Grüßen

[Freischreiber]

Hallo herz4,

nur einem(!) kleinen Häkchen an der - entscheidenden - Stelle, dem Menü Bearbeiten > Datenbank > Erweiterte Einstellungen unter "Die Rechte vom Datenbanktreiber ignorieren", eine für mich bis dato unverständliche Option.

Seltsam, bei mir ist diese Option aktiviert, und ich bin mir sicher, auf dem Reiter "Besondere Einstellungen" nie etwas angefaßt zu haben. Die Einstellung wird wohl Standard sein. Ob das in früheren Base-Versionen anders war, kann ich leider nicht mehr nachschauen. Es wäre aber sehr unwahrscheinlich, da sich in Base im Lauf der Jahre wirklich nur sehr selten irgendetwas ändert.

Ich finde es sehr gut, daß du hier ausführlich die Lösung aufgeschrieben hast. So hilft der ganze Thread auch anderen.

(Und wenn du gerade einen "Lauf" hast, plädiere ich immer noch für moderne Java- und HSQLDB-Versionen. Mein nächster Vorschlag wäre gewesen, beim Entwickler von HSQLDB mal anzufragen, ob der eine Idee hat, woran es liegen könnte. Aber der beantwortet vielleicht auch keine Fragen mehr zur Version 2.5.0.)

Herzlichen Glückwunsch und viele Grüße
Freischreiber

[herz4]

Hallo Freischreiber,

ich danke Dir für Deine Anteilnahme, Deinen Glückwunsch.

Ich muss gestehen, ich wusste gar nicht mehr wirklich, wie glücklich es einen machen kann, wenn man nach einer Woche Suchen, zahllosem nutzlosen Probieren und Bangen endlich die Lösung gefunden hat. Und es ist nur für ähnlich veranlagte "Bastler", Hobby-Programmierer verständlich, und auch nur unter dem Blickwinkel, dass der Fehler die bisherige Nutzung von Software in dem nahezu täglichen Umgang einschränkt oder fast schon verunmöglicht, so weit behindert, dass von "Nutzung" im eigentlichen Sinn keine Rede mehr sein kann.

Den ganzen gestrigen Tag war ich auch von meiner früheren Verlobten davon abgehalten worden, meine mit der Lösung schwangeren Gedanken auch in die Tat umzusetzen. Und heute Morgen gab es noch einen Moment höchster Anspannung: Das Setzen des Hakens hatte auch nach dem Schließen des Optionenfensters unmittelbar noch - keinen - (merklichen) Erfolg. Ich musste erst die Datenbankverbindung neu aufbauen lassen. Ich schloss Base, lud die odb-Datei neu. Erst dann, nach diesen letzten, bangen Sekunden hatte ich Erfolg.

Ja - va?! Ich will mal umgekehrt herangehen. Ich kam zu HSQLDB 2.5.0 vor ungefähr einem Jahr, als schon (mehrere) neuere Versionen existierten. Nur LO-Base ließ mich - mit Server-DB - nicht mit höheren Versionen "ruckelfrei" umgehen. Seinerzeit stand noch nicht die Benutzerverwaltung zwischen uns, ich war einziger SA. Ich bin jetzt neu daran interessiert, eine höhere HSQLDB-Version zu testen und schließlich zu übernehmen.

Da ist ein aktuelles Java nicht nur interessant, eher notwendig. Mit der manuellen Aktualisierung habe ich noch nicht viel Erfahrungen, verließ mich bisher weitgehend auf die Distribiutionspflege. Java ist hier aber am sensibelsten auf dem Server. Dessen Betriebssystem, ein Raspbian, muss auch (schon länger) aktualisiert werden. Wo fange ich an, wie weit gehe ich, um hinterher nicht doch wieder irgendwo downgraden zu müssen. Oder aber gilt noch besser: Never change a running system!?

Ich muss erst einmal einen Plan (á la Egon Olsen) machen ... und habe aber noch viele weitere.

Schönes Wochenende wünscht
herz4

P.S.

Seltsam, bei mir ist diese Option aktiviert, und ich bin mir sicher, auf dem Reiter "Besondere Einstellungen" nie etwas angefaßt zu haben.

Gut möglich, dass auch bei mir der "angeixelte" Zustand der Standard war. Im Zuge der Einrichtung mehrerer DB-Nutzer habe ich dann aber diese Option abgewählt, weil ich keinen "generellen" Datenzugriff (auch für Base und nunmehr ehemals) wollte (der auch damit gar nicht gegeben ist!).