Base-Anfängerprobleme

Liebe Liste,

ich habe nachdem ich mich lange nur um Calc und Writer gekümmert habe, mit Base angefangen.

Dabei stosse ich auf ein paar Probleme, die mir unverständlich sind, aber möglicherweise ihren Sinn haben:

Vorinfo: - ich arbeite mit LO 4.4.7.2 unter Win 7/64 mit allen Updates.
             - ich habe eine einfache Tabelle (HSQLDB) erstellt mit einen Primärschlüssel [BIGINT] zahlreichen Textfeldern [VARCHAR] und noch mehr ja/nein-Feldern
               [BOOLEAN]
             - die Tabelle enthält noch keine Daten, es gibt aber bereits ein Formular dazu

Die Probleme:

- es lassen sich grundsätzlich im nachhinein keine Änderungen in der Tabellendefinition vornehmen (wohlgemerkt, es gibt noch keine Daten-Einträge), es sei denn, man löscht einen Feldnamen (und damit die Eigenschaften wie Feldtyp) komplett und fügt ihn neu wieder ein. Das mag u.U. ja noch Sinn machen, aber ein Editieren der Beschreibung sollte doch wenigstens möglich sein.

- die meisten Feldeigenschaften kann ich verändern, doch überstehen diese Änderungen ein Speichern und Wideröffnen des Tabellenentwurfdialogs nicht. So möchte ich den Primärschlüssel auf Auto-Wert setzen [Feldname ID, BIGINT], das ist ganz ausgegraut und nicht zugänglich und ich möchte bei den ja-nein-Feldern den Default-Wert von <keiner> auf "nein" ändern. Das kann ich zwar machen, ich kann auch auf andere Einträge wechseln und wieder zurück zum geänderten Feld springen, es ist alles ok. Speichere ich jedoch und öffne den Tabellen-Bearbeiten-Dialog wieder, sind die vorgenommenen Änderungen bei den ja/nein-Feldern verschwunden, alles steht bei den Default-Werten der ja/nein-Felde wieder auf <keiner>.

Die Fragen: ist dieses Verhalten bei euch nachvollziehbar und vor allem: bug oder Feature (wobei es ja keinen Sinn macht, Änderungen zu ermöglichen, die nicht gespeichert werden können)? Gibt es eine Einstellung/einen Umstand, die/der dieses Verhalten bewirkt? Und vor vor allem: was kann ich tun, um die gewünschen Eigenschaften zu erreichen?

Für ein paar Hinweise dankt schon mal

Markus

Hallo Markus,

ich kann das Verhalten nicht nachvollziehen, es wäre auch auf keinen Fall ein Feature.
Ich habe es zwar gerade unter LO 5.1.1.3 und Windows 10 ausprobiert, habe aber ähnliches immer wieder mal in älteren Releases gemacht und noch nie dieses Phänomen gesehen.
Überprüfe erst einmal, ob du wirklich einen Primärschlüssel definiert hast, ohne den geht manches nicht.
Ansonsten solltest du die Datei .odb als Anhang ergänzen, dann lässt sich vielleicht mehr sehen.

Gerhard

Hallo Markus und Gerhard,

ich kann bestätigen, dass ich schon seit Version LO3.3 mit Base arbeite (heute 5.1.1.). Ich bin da auch nicht der große Profi, aber dieser Effekt ist bei mir auch noch nicht vorgekommen. Ich habe das auch mal kurz bei mir getestet. Tabelle und Fromular erzeugt. Änderungen in der Tabelle sind immer möglich.

Eine Anlage an die Liste funtioniert nicht, da Listen diese abschneiden.

Gerhard, vielleicht kannst Du Deine ODT-Datei irgendwo hochladen (Dropbox o.ä.) und den LINK hier publik machen.

Gruß
Harald (B.)

-----Original-Nachricht-----

Hallo Gerhard, hallo Harald, hallo Liste,

ich habe weiter experimentiert. Es ist wohl so, dass es sich NICHT um eine allgemeines Problem handelt, sondern um eine Problematik meiner Installation:

Es ist auffallend, dass sich Base nicht mehr (ordentlich) beenden lässt, nach den beschriebenen Änderungsversuchen. Entweder es bleiben die beiden Prozesse soffice.bin und soffice.exe aktiv (das Base-Fenster terminiert dann zwar, es lässt sich aber kein neues öffnen) oder es lässt sich sogar das Fenster nicht schießen (dann bleibt die Anwendung sbase aktiv). (Wohlgemerkt, Base lässt sich nicht schließen, der Dialog zum Bearbeitend er Tabellendefinitionen schon!)

Dieses Verhalten ist auf Base beschränkt, Writer, Calc, Draw und Impress verhalten sich erwartungsgemäß.

Ich denke, die beschriebene Problematik hängt mit den nicht dauerhaften Änderungen zusammen, deshalb dieses Post.
Hat jetzt jemand eine Idee?

Es dankt nochmals vorab

Markus

Hallo *,

ich habe weiter experimentiert. Es ist wohl so, dass es sich NICHT
um eine allgemeines Problem handelt, sondern um eine Problematik
meiner Installation:

Bei Problemen mit der individuellen Installation solltest Du immer
zuerst einmal ausschließen, dass Du irgendeine Einstellung gespeichert
hast, die Ursache für ein Fehlverhalten ist:
Speicherort für das Benutzerprofil
Unter Windows Vista/7: %appdata%\libreoffice\4\user
Hier einfach die '4' durch '4alt' ersetzen. Das Profil wird dann neu
geschrieben. Jetzt noch einmal Base neu starten und sehen, ob sich LO
anschließend auch wieder einwandfrei beenden lässt.

Es gibt zwar auch Bugmeldungen zu Crashes in Base - nur sind die alle
nicht allgemein nachvollziehbar ...

Zum AutoWert: Das funktioniert nur, wenn Du für das Feld "Integer" wähls
t.

Zu Standardeinstellungen: Solche Einstellungen in Tabellen bringen nur
etwas, wenn Du die Tabellen direkt für die Eingabe nutzt. Es handelt
sich dabei nicht um SQL-Standards, sondern um die Vorbelegung von
Feldern. Das kann genauso gut innerhalb eines Formulars definiert werden
.

Gruß

Robert

Hallo Markus,

hier ein Nachtrag:
http://www.libreoffice-forum.de/viewtopic.php?f=10&t=16182&sid=1d74fdfdf
af7b145091e3673c2143cbc#p41800

Ist im Forum ja nicht zu erkennen, wie die Leute tatsächlich heißen.
Stammt der Beitrag eventuell von Dir? LO-Version und Windowsversion
stimmen ...

Gruß

Robert

Hallo Liste,

zunächst besten Dank an alle, die sich dem Problem angenommen haben!

Zu dem von mir beschriebenen Problem gibt es bis jetzt zu berichten:

Problembeschreibung (aktualisiert seit der Ausgangsmail):

betrifft: LO 4.4.7.2 unter Win 7/64 mit allen Updates, Base mit einfacher Tabelle (HSQLDB)

1. Es trat das Phänomen auf, das viele Tabelleneigenschaften sich nicht mehr ändern ließen (ausgegraute Dialoge) oder die Änderungen nicht dauerhaft waren, d.h. nach 1x Schließen und wieder Öffnen verschwunden waren (davon betroffen z.B. die Änderung von Default-Werten von Ja/Nein-Feldern).

2. Zudem war der Verlauf des Beendens der Entwurfsansicht einer Tabelle nicht konsistent. Wurde der geänderte Entwurf gespeichert (Symbol "Speichern" angeklickt, danach war es - erwartungsgemäß - ausgegraut), so wurde beim Schließen der Entwurfsansicht dennoch ein "Speichern?"-Dialog angezeigt. Nachdem die Entwurfsansicht dann beendet war, war Base trotzdem in einem Zustand nicht gesicherter Änderungen ("Speichen"-Symbol nicht ausgegraut, auch wenn außer dem Tabellenentwurf keinerlei Änderungen vorgenommen wurden).

3. Im weiteren Verlauf kam es immer häufiger vor, dass die Entwurfsansicht der Tabellen sich gar nicht mehr schließen ließ und der Task Manager bemüht werden musste. Am Ende war dies immer so, der Versuch die Entwurfsansicht für Tabellen zu schließen (egal wie) führte zum Einfrieren von Base, andere parallel geöffnete LO-Anwendungen waren dann ebenfalls betroffen.

Maßnahmen:

1. das Erzeugen eines neuen User-Profils scheint das Problem zu lösen. Allerdings bleibt unklar, was das Problem ausgelöst hat. Deshalb schreibe ich auch "scheint" das Problem zu lösen, da nicht abzusehen ist, ob es ggf. wieder auftritt. Alle Dialoge verhalten sich erwartungsgemäß, Änderungen bleiben erhalten.

2. es wurde vermutet, dass die Java-Version nicht zu Base/LO passt v.a. in Bezug auf die Wortbreite (32/64bit). Dazu ist anzumerken. LO 4.4.7.2 für Windows existiert nur in 32bit. Eine 64bit-Version von Java wird, so am System angemeldet als fehlerhaft erkannt. Base funktionierte dann allerdings in Bezug auf das Beenden normal, sinnvolles Arbeiten war jedoch aufgrund der fehlenden Java-Funktionalität nicht möglich. Mit angemeldetem 32bit-Java trat das oben beschriebene Verhalten auf. Eine falsche Wortbreite der Java-Version wird also von LO/Base erkannt (wenn vielleicht auch nicht mit einer eindeutigen Meldung).

3. es wurde vermutet das die verwendete Java-Version 8 - 77 (also 1.8.0.77, 32bit, März 2016) nicht zur nicht mehr 100% taufrischen LO-Version 4.4.7.2 (Ende Nov. 2015) passt. Das lässt sich nachprüfen, da ältere Java-Versionen nicht mehr zum Download angeboten werden. Die Verwendung älterer Java-Versionen wäre mMn auch wegen der damit verbundenen Sicherheitsrisiken keine gute Lösung.

Beste Grüße

Markus