=IF(ISNA(VLOOKUP(... liefert in seltenen Fällen falsche Ergebnisse

[jmattern]

Moin alle miteinander.

Ich bin vor kurzem von Open Office auf Libre Office umgestiegen. Einer der Gründe war, dass Open Office die Spaltenzahl pro Sheet immer noch auf 255 begrenzt. Ich habe nun ein älteres Sheet über diese Grenze hinaus erweitert. Dabei ist zu beobachten, dass eine bestimmte Formel ( =IF(ISNA(VLOOKUP(;;;FALSE());; ) ) sporadisch falsche Ergebnisse liefert.

Dabei sind zwei Varianten aufgefallen:

1. VLOOKUP() liefert korrekt NA, ISNA() liefert korrekt TRUE, aber IF() gibt den dritten Parameter, den False-Wert zurück.

2. VLOOKUP(;;;FALSE()) liefert NA, obwohl ein passender Wert in der Tabelle vorhanden ist.

Für beide Fälle gilt: Öffnet man nach der Berechnung den Function Wizzard, zeigt dieser das richtige Formelergebnis an, während gleichzeitig noch der falsche Wert in der Zelle zu sehen ist.

Der Effekt scheint nur aufzutreten, wenn die zu verarbeitende Formelmenge groß genug ist. Bei deutlich kleineren Dateien habe ich den Effekt bisher nicht bemerkt.

Screenshots

Die Tücke des Objekts -1.-

Der Upload-Filter lässt mich nur einen Screenshot anhängen:

Function wizzard (für beide Fälle analog)

Testdatei

Die Tücke des Objekts -2.-

Hier sollte eigentlich eine Testdatei folgen, aber der Upload-Filter meldet
Sorry, that file is too big (maximum size is 4 MB). Why not upload your large file to a cloud sharing service, then paste the link?
obwohl die Datei “nur” 3,6 MB groß ist. Ein cloud sharing service steht nicht zur Verfügung.

Als zip-Datei lässt er sie auch nicht durch.

Ich werde versuchen, die Datei noch weiter zu verkleinern ohne den Effekt zu verlieren.
Event. hat ja jemand in der Zwischenzeit einen Vorschlag, wie ich die Datei anderweitig loswerden kann.

Versionsinfo

Da ich keinen Screenshot ablegen kann und da man aus dem About-Dialog von Libre Office keinen Text herauskopieren kann, hier also abgetippt :

Version: 7.5.8.2 (X86_64) / LibreOffice Community
Build: f718d63693263970429a68f568db6046aaa9df01
Environment: CPU threads: 20; OS: Windows 10.0 Build 22631
…

Die Angabe Windows 10.0 ist falsch, ich habe Windows 11 Build 22631.2715

Viele Grüße
jmattern

[erAck]

Tja was soll man dazu ohne Dokument schon sagen… der Screenshot hilft hier nicht viel.

@jmattern

Ein cloud sharing service steht nicht zur Verfügung

Es gibt jede Menge File-Hoster wo man mal eine Datei ablegen kann. z.B. https://gofile.io/

@jmattern

Als zip-Datei lässt er sie auch nicht durch.

.ods (und alle LO .od*) Dateien sind schon gezipt, das würde also nichts bringen.

@jmattern

da man aus dem About-Dialog von Libre Office keinen Text herauskopieren kann

Doch, kann man, einfach den Button im Dialog klicken. Aber danke, dass du dir die Mühe gemacht hast.

[jmattern]

Danke für die Antworten.

Hier die Versionsinfo:

Version: 7.5.8.2 (X86_64) / LibreOffice Community
Build ID: f718d63693263970429a68f568db6046aaa9df01
CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL threaded

Wie schon gesagt, muss man Windows 10 durch Windows 11 ersetzen.

Und der Link:

BL V1.8.0.2.TEST c.ods

Die Screenshots spare ich mir. Das Rechenergebnis ist richtig, wenn die beiden Flags gleich sind (0-0) bzw. (1-1). Fall 1 liefert (0-1), Fall 2 (1-0), was beides inhaltlich falsch ist, wie auch der Wizzard anzeigt.

[erAck]

Die Ergebnisse sind bereits falsch gespeichert und werden nach dem laden so angezeigt falls die Formel nicht eh neu berechnet werden muss. Einmal mit Shift+Ctrl+F9 alles hart neu berechnen hilft. Falls das erneut auftritt, könnte die Ursache vielleicht CL threaded sein, dann mal probieren, unter Optionen → LibreOffice → OpenCL das auszuschalten.

[jmattern]

Hallo erAck,

OpenCL zu deaktivieren hat keinen Effekt (außer einer leichten Performanceeinbuße).

Das andere verstehe ich nicht. Ich habe das Testsheet ja extra so gebaut, dass man durch F9 sehen kann, dass das Problem mal auftritt und mal nicht !?

J.

[jmattern]

Oh sorry,

habe gerade gesehen, dass ich im ersten Post was Wichtiges vergessen habe:

Damit der Effekt bei gleichen Inputdaten besser sichtbar ist, habe ich die RAND() Funktion genutzt. Durch Aktualisieren (F9) werden immer wieder neue Ergebnisse errechnet, sodass man mit etwas Geduld den Effekt reproduzieren kann.

(Falls eine der Varianten in der Testdatei gespeichert sein sollte, ist das keine Absicht.)

[erAck]

Tja ¯\(ツ)/¯ ich kann das zwar gelegentlich reproduzieren, dass RQ18 nicht zu dem Ergebnis in RO8 passt, aber da kann ich nur empfehlen, einen Bugreport aufzumachen und die Datei anzuhängen. Und bitte beschreiben, wonach zu gucken und zu suchen ist (welche Zelle wenn was und so weiter), hier war das eher ein Glücksspiel…

[jmattern]

Glücksspiel ist das passende Wort.

Danke, dass Du drauf geschaut hast.

Wünsche noch einen schönen Abend.
J