LibreOffice-Forum

Hallo liebe Gemeide,
ich verzweifel schon fast. Ich möchte zum ersten Mal auf dem neuen Rechner eine Datenbank mit base erstellen.
Ob ich die DB selber oder mit dem Assistenten erstelle ist egal. Jedes Mal, wenn ich die Entwurfsansicht oder den Assitenten anklicken kommt die Fehlermeldung:
Die Verbindung zur Datenquelle konnte nicht herstellt werden. Es konnte keine Java Installation gefunden werden.
Diverse Foren Durchsucht und natürlich unter Optionen Extra die Java - Installation ( die auch angezeigt wird ) ausgewählt. LO - Base neu gestarte und der Fehler bleibt.
Java deinstalliert und neu installiert = Der Fehler bleibt.

Hat noch jemand einen Tipp für einen verzweifelten Menschen?

Ich habe Windows 7 (32 Bit) und LO 3.5.5

Danke für das Nachdenken.

Selbst gelöst!
Java 7 funzt nicht, wohl aber Java 6

Es reicht nicht aus, JRE zu installieren. Unter Extras/Optionen.../LibreOffice/Java muss die Laufzeitumgebung auch aktiviert werden.

Gerade stelle ich dasselbe Problem fest, aber in der aktuellen Version (4.0.2) schien die Lösungsmöglichkeit (Extras/Optionen/.../Java) verschwunden.
An fehlender 32bit-Version( http://www.libreoffice-forum.de/viewtop ... t=10201%20) der JRE lag es auch nicht, allerdings war die nur die aktuelle Version der 7er-Serie installiert. LibreOffice 4.0.2 hingegen scheint noch immer auf die JRE aus Versionsreihe 6 (http://java.com/de/download/manual_v6.jsp) zwingend angewiesen - entgegen der Aussage "Support for Java 7 (1.7) added. User can select between Java 6 or 7 engine, if both are installed." (https://www.libreoffice.org/download/3- ... and-fixes/).

Schade aus mehrenen Gründen:

1) "Nach Februar 2013 stellt Oracle keine Updates mehr von Java SE 6 auf seinen öffentlichen Downloadsites bereit. Alle Java 6-Releases bis zu einschließlich 6u45 werden in das Java-Archiv in Oracle Technology Network verschoben, wo sie weiterhin verfügbar sind, aber keine Updates für sie angeboten werden. Oracle empfiehlt, dass Benutzer zu Java 7 migrieren, um weiterhin öffentliche Updates und Sicherheitsverbesserungen zu erhalten." Zitat von http://java.com/de/download/faq/java_6.xml

2) Der Dialog "Die Konfiguration von LibreOffice wurde geändert. Wählen Sie unter Extras - Optionen... - LibreOffice - Erweitert eine Java-Laufzeitumgebung aus, die von LibreOffice benutzt werden soll" erscheint offenbar erst in dem Moment, in dem verschiedene alternativ nutzbare Java-Versionen installiert SIND. Wer in der irrigen Auffassung, die aktuelle 32-Bit-Version sei passend, nur diese installiert hat, sucht deshalb möglicherweise unnötig lange nach der an sich einfachen Lösung, zumal die Konfigurationsoption jetzt unter "Erweitert" und nicht mehr "Java" zu finden ist. Die Anzahl der Aufrufe von http://www.libreoffice-forum.de/viewtop ... =10&t=6520 mag für sich sprechen.


Irgendwie scheint Base in der Version 4 (4.0.2.2 auf Windows 7, 64bit) generell arg gelitten zu haben. Dateien (mit per HSQLDB eingebetteten Tabellen), die unter 3.6.5 einwandfrei liefen (und es auch wieder tun, wenn man zur 3.6.5 zurückkehrt), können wahlweise entweder auf ihre Tabellen nicht mehr zugreifen oder bringen - ohne Änderung an den Makros - plötzlich Fehlermeldungen wie "com.sun.star.sdbc.SQLException Message: No data is available.", "Fehler in der Funktionsfolge" und ähnliches. Das mag zumindest zum Teil mit der JRE-Version zusammenhängen, doch eine zu finden, mit der alles funktioniert, ist mir leider nicht gelungen. Nur das Downgrade auf 3.6.5 half (und belegt überdies, daß es sich nicht um korrumpierte Dateien oder Syntaxfehler handelt).

Zusammengefaßt darf ich GreySound's Feststellung erweitern: "Java 7 funzt nicht, wohl aber Java 6, allerdings auch nur mit LibreOffice 3"

Hallo Devdol,

ich habe keine Unverträglichkeiten von Java 7 mit LO-Base bisher feststellen können (allerdings: Linux 32bit rpm). Auch sonst wird davon in den Bug-Meldungen nichts mehr berichtet. Wenn es bei Dir anders sein sollte, dann solltest Du eine entsprechende Bug-Meldung aufgeben.

Was hingegen schon hinreichend als Bug gemeldet ist, das sind Unverträglichkeiten mit der Reihenfolge von Funktionsaufrufen über Makros in Base:
https://bugs.freedesktop.org/show_bug.cgi?id=63398
https://bugs.freedesktop.org/show_bug.cgi?id=63291
Das ist neu in LO 4.0 und leider noch nicht behoben.

Gruß

Robert

Lieber Robert,

vielen Dank für die schnelle und sehr gehaltvolle Antwort! Die diversen von mir mit der V. 4.0.2.2. beoachteten Fehler traten auf etwa einem Dutzend Rechnern unter Windows 7, 64 bit, auf. Bei der Anwendung handelt es sich um ein kleines Formular zur Aktualisierung der diversen installierten (freien) Software, die aus eben diesem Grund auf dem Fileserver liegt. Hauptproblem war stets die Unfähigkeit, auf die eingebetteten Tabellen zuzugreifen, was sich durch (zusätzliches) Installieren der entsprechenden älteren 6er JRE lösen ließ. (Da man als bescheidener Nicht-Entwickler den Fehler eher bei sich selbst vermutet, habe ich von einem Bugreport bisher abgesehen.) Eine schöne Lösung ist das freilich nicht, da zum einen die "herumliegende" alte JRE potentielle Sicherheitslücken "bereitstellt", zudem durch das Autoupdate der JRE möglicherweise bisweilen gestört wird (wie stabil die einmal in LibreOffice eingestellte Direktive, eine spezielle JRE zu verwenden ist, habe ich noch nicht überprüft). Auf jeden Fall ist die nostalgisierende Zusatz-JRE eigentlich schon mal überflüssige Arbeit.

Die anderen beiden Bugs (63398 und 63291) sind hingegen "bis auf weiteres" echte Showstopper, da ich wegen der kleinen Base-Anwendung überall das alte LibreOffice installiert lassen müßte und doch andererseits den Nutzern eigentlich der anderen Anwendungen wegen gerne ein aktuelles LO bereitstellen würde. Daher versuche ich mittelfristig die kleine Anwendung lieber in Lazarus (http://lazarus.intern.es/sqlite_lazarus.html) hinzubekommen. Erste Gehversuche damit sind vielversprechend, vor allem natürlich in puncto Geschwindigkeit - logisch.

Besonders herzlichen Dank auch für das "Handbuch", auf das ich bisher nicht gestoßen bin!

In Bezug von JAVA JRE 6 dürften einige Angaben unzutreffend sein.

1. Als im Februar 2013 die Einstellung der Fortentwicklung von JRE 1.6 angekündigt wurde, waren wir bei der Versions-Nr. 1.6.0_39
2. Aktuell (Stand April) sind wir nun bei der Versions-Nr. 1.6.0_45 angelangt. Dies besagt, dass zwar die Fortentwicklung eingestellt ist, aber Sicherheitslücken geschlossen werden.
3. Hier kann nach wie vor die die aktuelle JRE 1.6 herunter geladen werden.

Hallo, ich bin heute schon wieder am bislang erfolglosen Versuch, die Tabellen bzw. HSQL wiederzubeleben.

Also im Detail (alle installierten JREs 32 bit, OS = Windows 7 64 bit frisch installiert in VirtualBox; LibreOffice: 3.6.6. deutsch; Eingebettete Datenbank | HSQL ):

• Oracle Corporation 1.7.0_21 --> General error: org.hsqldb.lib.FileSystemRuntimeException: java.io.IOException: C:/onegit/package/source/xstor/xstorage.cxx:3172:
  Sun Microsystems Inc. 1.6.0_45 --> General error: org.hsqldb.lib.FileSystemRuntimeException: java.io.IOException: C:/onegit/package/source/xstor/xstorage.cxx:3172:
  Sun Microsystems Inc. 1.6.0_43 --> General error: org.hsqldb.lib.FileSystemRuntimeException: java.io.IOException: C:/onegit/package/source/xstor/xstorage.cxx:3172:
  Sun Microsystems Inc. 1.6.0_22 --> General error: org.hsqldb.lib.FileSystemRuntimeException: java.io.IOException: C:/onegit/package/source/xstor/xstorage.cxx:3172:

Nach jedem Versuch wurde LibreOffice jeweils geschlossen und neu gestartet, wie es das auch selbst anfordert.
Die Makros wurden dabei nicht aktiviert, um es möglichst einfach zu halten.
Die zuvor eingestellte Version ist danach auch korrekt unter "Extras/Optionen/Java" mit einem Radiobutton selektiert.

Insbesondere die funktioniert in unserem Kontext also nicht.
http://www.oooforum.org/forum/viewtopic.phtml?t=62868

Nochmalige Reinstallation von der genannten Quelle (http://download.oracle.com/otn-pub/java ... s-i586.exe) - gleiches Ergebnis wie oben.
Das ist insbesondere kurios, da alles mit JRE 1.6.0_22 schon mal monatelang gelaufen war.

Die Verzweiflung des OP ist durchaus nachvollziehbar.

Hast Du schon einmal das Benutzerverzeichnis umbenannt ? Das bewirkt oft wahre Wunder.

Wieder ein Rätsel gelöst: Der ganze Spuk lag augenscheinlich an der Verknüpfung, über welche die Anwendung am Client gestartet wurde.
Hier war kein (mit "net use" gemappter) Pfad mit Laufwerksbuchstaben, sondern ein UNC-Pfad eingetragen - und an dem scheint sich die JRE bezüglich HSQLDB zu verschlucken. Seitdem dieser Pfad gegen ein gemapptes Netzlaufwerk ersetzt ist, ist der Zugriff auf die Tabellen wieder möglich - und in der Tat anders als von GreyHound oben vor 10 Monaten beschrieben dann inzwischen auch mit JRE Version 1.7.0_21.

(Der Basic-Code hingegen kommt nach wie vor auch mit UNC-Pfaden klar, insofern lag die Notation des Pfadnamens als mögliche Ursache für mich nicht so offensichtlich auf der Hand.)

Danke allen für die verschiedenen Anregungen!