gelöst: Zellen werden unzuverlässig aktualisiert

[felixed]

Zuerst die Lösung: Das Problem scheint nur die 64bit-Windoofs-Versionen zu betreffen. Nach Deinstallation und Installation der 32bit-Variante trat der Fehler nicht mehr auf.

Betrifft LO 6.06: Bei Wertänderungen werden sich darauf beziehende Zellen mal aktualisiert, mal nicht, und das in derselben Tabelle in denselben Spalten in untereinanderstehenden Zeilen. (In dem Falle war's 'ne Mittelwertbildung.) Ein Muster, wann aktualisiert wird und wann nicht, habe ich nicht erkannt.
Aktualisieren ist selbstverständlich aktiviert.
Irgendwelche Ideen?

Nachtrag: Fehler besteht in der Windows-Version 6.06; kein Fehler in der Linux-Version 5.4.

[Mondblatt24]

Hallo,
es gibt die Finale Version der 6.0er Reihe - 6.0.7.3 zum zum Download

Gruß Peter

[felixed]

Kleine Ergänzung: Unter Windows 7 64bit machen das sowohl 6.06 als auch 5.47. Wie gesagt, in der Linux-Version nicht.

Ich habe noch bißchen 'rumprobiert: dieselben Zellen werden mal aktualisiert und mal nicht, das Verhalten ändert sich völlig unberechenbar, mal sind's Zellen oben in der Tabelle, mal welche weiter unten, mal gehen alle - und beim nächsten Versuch ist wieder alles anders. Wenn man den Rechner ein paar Minuten in Ruhe läßt, werden die Zellen auch nicht aktualisiert.

[100]

[GELÖST durch Version 24.8.3.2, siehe Edit 7]

Ich habe das Problem seit ein paar Tagen auch. Version 24.8.2.1 x64, unter Windows 10 22H2. Bemerkt habe ich es an einer Zelle mit "=JETZT()". Da wird nach einer Eingabe in eine andere Zelle nach einiger Zeit die Uhrzeit nicht mehr aktualisiert, und alle von ihr abhängigen Zellen dann natürlich ebenfalls nicht. Erst wenn ich die Tabelle schließe und sie neu öffne, funktioniert es wieder eine Zeit lang.

Ich kann einen zeitlichen Zusammenhang mit dem Wechsel von Java
"JRE 17 LTS (17.0.12+7)" auf die
"JRE 21 LTS (21.0.5+11)" herstellen, weshalb ich gerade eben auf die
"JRE 17 LTS (17.0.13+11)" gewechselt habe. Alle Versionen sind "Eclipse Temurin Hotspot". Hoffentlich ist das Problem damit erst mal umgangen.

Edit: Daran lag es leider nicht, denn auch mit der "JRE 17 LTS (17.0.13+11)" trat es wieder auf. Interessanterweise betrifft es dann aber nur diese Tabelle. Eine parallel geöffnete Test-Tabelle, die nur eine Zelle mit "=JETZT()" enthält, aktualisierte die Zeit weiterhin sofort, wenn man in einem anderen Feld eine Eingabe abschließt oder den Wert löscht.

Ich habe jetzt mal eine alte Version der Tabelle aus einer Sicherung geholt und sie auf den aktuellen Stand gebracht. Tritt es da dann nicht auf, muss die andere irgendwo einen Defekt haben. Was ich noch beobachtet habe: Wenn sie nicht mehr rechnet und ich einfach woanders ebenfalls "=JETZT()" in ein leeres Feld setze, funktioniert wieder alles und beide Felder werden gleichzeitig aktualisiert. Gebe ich aber stattdessen einfach einen Wert in ein leeres Feld, hebt das die Blockade nicht auf. Nur ein Neustart der Tabelle oder eben obige Zeitformel. Sehr seltsam!

Den Virenscanner habe ich noch in Verdacht, denn da gab es vor einigen Tagen die neue 2025er Version. Da könnte ich die jetzt alte Tabelle mal in die Ausnahmen setzen und sie parallel zur jetzt neuen Tabelle aus dem aktualisierten Backup geöffnet lassen.

Edit 2: Es tritt jetzt nicht mehr auf. An der Ausnahme der betroffenen Datei im Virenscanner kann es aber nicht liegen, denn dann müsste es bei der Version aus dem Backup auch auftreten, da ich die nicht in die Ausnahmen nahm. Ein Defekt der Datei scheidet auch aus, denn defekt wäre sich ja nach wie vor. Ich hatte aber das »Temurin Java-JRE« Setup nochmal aufgerufen und da fiel mir auf, dass ich vergessen hatte, die »Java_Home Variable« zu setzen. Ich hatte lediglich die untere Option aktiviert, also nur den »Javasoft Registry-Eintrag« gesetzt. Jetzt ist beides gesetzt. Aber wenn es das war, hätten ja auch beide Dateien betroffen sein müssen. Es bleibt wohl ein Rätsel. Hoffentlich kommt es nicht doch wieder.

Edit 3: Mist, nachdem der Rechner zweimal mit den geöffneten Tabellen im Ruhezustand gewesen war, trat es wieder auf – bei beiden Tabellen, bei der Test-Tabelle jedoch nicht. Mit F9 ließ sich das Zeitfeld aktualisieren und somit aktualisierten sich auch die Zellen, die davon abhängen.

Bei der alten Tabelle habe ich mal die manuelle, also direkte Formatierung der Spalte mit den Zeiten eines bestimmten Zeitraums gelöscht, also nicht in allen Zeilen, und diese dann neu formatiert. Später musste ich feststellen, dass in 2 anderen Spalten (AB/AE) plötzlich die bedingte Formatierung genau in den Zeilen kaputt war, die ich in der Zeitspalte manuell neu formatiert habe. AB/AE hatten in diesen Zeilen plötzlich die Formatierung der Spalten AA/AD.

Hä? Die Spalte (A) mit den Zeitangaben hatte gar keine bedingte Formatierung. Wie kann das Löschen der dortigen manuellen Formatierung die bedingte Formatierung der Spalten AB/AE beeinflussen und sie auf die von AA/AD umstellen?

Es deutet also alles stark darauf hin, dass die Tabellen korrupte Formatierungen haben, in dem Sinne, dass es da Verbindungen gibt, die es nicht geben dürfte. Ich habe keinen blassen Schimmer, wodurch das passieren konnte. Wenn ich mal beim Erweitern der Tabelle versehentlich seitwärts statt nach unten gezogen hätte, hätte ich ja in den Zellen völlig falsche Werte gehabt.

Ich muss mir wohl die Mühe machen, bei den bedingten Formatierungen zu prüfen, auf welche Spalten und Zeilen sie wirken, und werde da sicherlich Fehler finden und Korrekturen vornehmen müssen.

Edit 4: (auch Edit 3 präzisiert) Noch mal bezüglich eines zeitlichen Zusammenhangs mit diesem erst kürzlich aufgetretenen Problem: Es muss erst mit der Version 24.8.2.1 begonnen haben. Allerdings muss ich zugeben, dass ich keine Lust verspüre, das mit Vorversionen zu testen. Ich habe auch nicht genau analysiert, welche bedingten Formatierungen nun auch welche nicht gewünschten Zellen mit einbezogen, denn die Anzahl an überhaupt einbezogenen Zellen war recht lang. Deshalb schaute ich nur flüchtig drüber, entdeckte mehrere Stellen mit AB/AE und entschloss mich kurzerhand, alle bedingten Formatierungen komplett neu zuzuweisen.

Edit 5: Das gibt es doch nicht: Nach dem Aufwachen aus dem Ruhezustand aktualisiert sich die Zeitzelle nach Änderung eines Wertes schon wieder nicht mehr selbstständig und ich muss es mit F9 erzwingen. Ich deinstalliere diese Libre Office Version jetzt und gehe runter auf die 24.2.7. Die bedingten Formatierungen sind nämlich in Ordnung!

Edit 6: Ha, mit der Version 24.2.7.2 tritt das Problem nicht auf. Demnach muss es ein Bug in der 24.8.2.1 sein. Aber einen Bug-Report kann ich dafür wohl nicht erstellen, denn dazu müsste ich ja meine Tabelle zur Verfügung stellen, da es in der Test-Tabelle, die lediglich aus einer genutzten Zelle [=JETZT()] besteht, nie auftrat. Allerdings war die nicht mit farbigem Hintergrund formatiert. Ob das den Bug triggert? Eigentlich ist das kaum vorstellbar, aber ich halte nichts für unmöglich.

Ich hatte jahrelang stets die Previous-Releases genutzt und war erst vor einigen Tegen mit der 24.8.2 auf den Zweig der Latest-Releases gewechselt. Daher kann ich nicht sagen, ob der Bug auch schon in der 24.8.1 vorhanden ist, vermutlich aber schon. Natürlich bleibe ich jetzt wieder bei den Previous-Releases. Die 24.8. werde ich aber komplett auslassen, auch wenn sie irgendwann zur Previous-Release wird. Ich springe dann gleich auf die 25.2., nachdem diese zur Previous-Release geworden ist (vermutlich also ab August/September 2025). Zwischendurch teste ich Kopien der Tabelle (auch vereinfachte, für eine Bug-Meldung) mit den portablen Versionen ab 24.8.3, die derzeit noch nicht verfügbar ist.

Edit 7 und Abschluß (19.11.2024): Ich habe nun doch mal die reguläre 24.8.3.2 probiert, da die portable noch nicht verfügbar ist und habe Glück, denn der Bug ist darin nicht mehr vorhanden. Er betrifft also glücklicherweise ausschließlich die 24.8.2.1.