![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Hallo Boris,
kannst Du für das Problem einmal eine Beispieldatei irgendwo zur
Verfügung stellen, damit ich das mir anschauen kann? Ich habe zwar
nichts mit Calc zu tun, aber hier alle möglichen LO-Versionen parallel
installiert.
Taucht das speziell bei der oben genannten LO 4.3.7.2 auf?
Gruß
Robert
Hallo Robert,
Hallo Boris,
kannst Du für das Problem einmal eine Beispieldatei irgendwo zur
Verfügung stellen, damit ich das mir anschauen kann? Ich habe zwar
nichts mit Calc zu tun, aber hier alle möglichen LO-Versionen parallel
installiert.
muss ich nur die wichtigsten Daten anonymisieren, hier zu finden:
http://www.kirk.de/files/2016-03-13_SVERWEIS-Test.ods
Taucht das speziell bei der oben genannten LO 4.3.7.2 auf?
Bisher habe ich nur diese Version probiert. Bei früheren Problemen mit
dieser Funktion habe ich feststellen müssen, dass diese sich mit
späteren Versionen eher noch verschlimmert haben; deshalb hält sich hier
meine Zuversicht in Grenzen. Die 3er Versionen erwiesen sich hier zwar
als fehlerarm, aber bei großen Dateien bei weitem zu langsam. Da
zweifle, in welche Richtung ich gehen sollte.
Hallo Boris,
ich hab jetzt die Formel selber eingegeben:
https://dl.dropboxusercontent.com/u/3483911/2016-03-13_SVERWEIS-Test-AK.ods
jetzt sollte es funktionieren.
Ein Unterschied ist auch, dass kein $ vor dem Tabellenblattnamen steht:
=SVERWEIS(B2;Mieten.$A$2:$B$43;2;0)
Tschuldigung, die erste Mail ging leider direkt an Dich, Boris. Hier
noch einmal für die Liste ...
Hallo Boris,
ich konnte den Fehler in der ersten Zeile reproduzieren. Dann habe ich
nachgesehen, warum da kein entsprechender Wert gefunden wurde: Der
entsprechende Name endete mit zwei Leerzeichen. Korrigiert und
korrekte Anzeige erhalten.
Schau Dir einfach einmal die Bezeichnungen für die Namen an, bei denen
der Namen direkt darüber wiedergegeben wird.
Gruß
Robert
Für eine Ergänzung kapere ich mal meinen alten Thread:
inzwischen musste ich feststellen, dass LO nicht nur Probleme mit dem
Finden in anderen Dateien hat, sondern auch innerhalb derselben Datei.
Besonders schlimm ist es, dass hierbei dann nicht etwa #NV erscheint,
sondern schlicht ein falscher Wert.Beispiel:
In Tabelle2 stehen in Spalte A Namen (alphabetisch sortiert) und in
Spalte B Zahlen dazu.In Tabelle4 stehen in Spalte B Namen aus der Menge der Spalte A in
Tabelle2. In Spalte D sollen nun mit SVERWEIS() die passenden Zahlen aus
Tabelle2 herausgesucht werden:=SVERWEIS(B2;$Tabelle2.A$2:B$50;2;1)
Das funktioniert bei den meisten Zeilen korrekt, doch bei einigen stehen
falsche Zahlen drin -fatal, weil man es kaum bemerken kann.
Kein Wunder, wenn Du einen falschen Parameter benutzt. Ich zitiere mal
aus der Hilfe (die entscheidende Passage hab ich hervorgehoben):
Sortierreihenfolge ist ein optionaler Parameter, der anzeigt, ob die
erste Spalte in der Matrix in aufsteigender Reihenfolge sortiert
wird. Geben Sie den booleschen Wert FALSCH oder Null ein, wenn die
erste Spalte nicht in aufsteigender Reihenfolge sortiert wird.
*Sortierte* *Spalten* können viel schneller durchsucht werden, und
die Funktion *gibt* *immer* *einen* *Wert* *zurück*, *selbst* *dann*,
*wenn* *für* *den* *Suchwert* *keine* _/*exakte*/_ *Übereinstimmung*
*gefunden* *wurde*, wenn er zwischen dem niedrigsten und dem höchsten
Wert der sortierten Liste liegt. In unsortierten Listen muss für den
Suchwert eine exakte Übereinstimmung gefunden werden. Anderenfalls
gibt die Funktion folgende Meldung zurück: Fehler: Wert nicht
verfügbar.
Im Detail
sieht das dann meist so aus, dass stattdessen die Zahl der Spalte über
der Fundstelle in Tabelle2 steht. Eine Regelmäßigkeit habe ich nicht
gefunden: weder tritt es alle x Zeilen auf, noch bei Namen mit Umlauten
oder irgendwelchen Ähnlichkeiten, bestimmten Längen oder wasweißich.
Aber vermutlich [tm] bei allen Namen, die nicht in der Quellmatrix
vorhanden sind. Die Groß-/Kleinschreibung ist dabei zwar egal, aber
nicht Schreibfehler oder überschüssige Leerzeichen usw.
Immerhin kann man die Fehlfunktion verifizieren: ändert man die Formel auf
=SVERWEIS(B2;$Tabelle2.A$2:B$50;1;1)
müsste der Name, der in Tabelle4.B2 steht, in Tabelle2, Spalte A
gefunden werden. Ausgegeben wird stattdessen der Name, der in Tabelle2,
Spalte A über dem gesuchten steht.
Also der nächstniedrigere. Das spricht deutlich für einen Schreibfehler.
Und genau das Verhalten ist bei Sortierreihenfolge=1 auch genau so gewollt.
Lies die Hilfe.
Aber es geht noch weiter: setzt man den Wert für 'sortiert', also den
letzten Parameter in der Klammer von WAHR auf FALSCH (bzw. 1 auf 0), so
wird der Name nicht mehr gefunden, obwohl sich an Tabelle2 nichts
geändert hat.
Und daran kannst Du auch ganz klar erkennen, dass da irgend ein
Schreibfehler vorliegt. Wo genau liegt Dein Problem?
Wer
auf die Funktion angewiesen ist, sollte sich besser nach etwas anderem
umsehen,
NAK; wer auf die Funktion angewiesen ist, sollte sie einfach nur korrekt
benutzen.
bis das gründlich gefixt ist, denn das macht alles kaputt. Für
mich hieße das wohl eine Odyssee durch die verschiedenen Versionen,
Das wird Dir nix nützen; der Fehler sitzt /vor/ dem Bildschirm, nicht
dahinter.
und
falls das nichts bringt, womöglich eigens dafür der Wechsel der
Anwendung, des Betriebssystems und damit einhergehend die Neuanschaffung
eines Rechners, Umbau des Netzwerkes oder die Rückkehr zu Papier und
Stift...
Bitte, kannst Du gerne machen.
Im Moment bin ich etwas ratlos, was ich tun soll.
Tief durchatmen, und den Fehler bei *Dir* suchen statt bei *anderen*.
Hint: Es gibt verschiedene Möglichkeiten, um Schreibfehler sichtbar zu
machen. Mit am einfachsten ist die bedingte Formatierung ("Format =>
bedingte Formatierung => [X] Bedingung 1 => 'Formel ist' =>
ISTFEHLER(SVERWEIS(B2;$Tabelle2.$A$2:$B$50;1;0)) => Neue Vorlage =>
Hintergrund = Rot" o. ä.). Eine andere wäre, mit "Daten => Gültigkeit"
zu arbeiten (das hilft aber leider nur gegen /neue/ Fehler, nicht gegen
bereits vorhandene).
Wolfgang
Hallo,
Kein Wunder, wenn Du einen falschen Parameter benutzt. Ich zitiere mal
aus der Hilfe (die entscheidende Passage hab ich hervorgehoben):
ich habe ihn keineswegs falsch benutzt, und das ist auch nicht der
Fehler. Vielmehr zeigt die Verwendung des Parameters, dass in der
Funktion gleich zwei Fehler vorliegen.
Zunächst: die Liste, die durchsucht wird, ist sortiert. Somit müsste die
Funktion mit beiden möglichen Werten die richtige Zeile finden. Je nach
Konstellation findet sie aber entweder nichts oder die falsche Zeile
(!). Auch wenn man die Sortierung bricht, wird es nicht besser, denn
dann findet die Funktion mitunter nur noch eine Minderzahl der Einträge,
die vorhanden sind. Zusammen mit den schon früher beschriebenen
Fehlfunktionen, wenn die Liste sich in einer anderen Datei befindet,
kann ich nicht anders als die Funktion als mindestens nahezu unbrauchbar
kaputt zu bezeichnen.
Also der nächstniedrigere. Das spricht deutlich für einen Schreibfehler.
Und genau das Verhalten ist bei Sortierreihenfolge=1 auch genau so gewollt.
Lies die Hilfe.
Habe ich, denn das tue ich als erstes. Aber man sollte sie auch
verstehen. Es kann nicht gewollt sein, dass die Funktion bei *korrekter*
Anwendung falsche Ergebnisse liefert. Eine falsche Fehlermeldung könnte
man sich vielleicht noch irgendwie schönreden, aber nicht ein zufälliges
Ergebnis.
Und daran kannst Du auch ganz klar erkennen, dass da irgend ein
Schreibfehler vorliegt. Wo genau liegt Dein Problem?
Man könnte jetzt sagen, dass in den Daten ein Schreibfehler vorliegt.
Aber dann sollte die Funktion auch korrekt darauf reagieren. Wenn also
die Funktion nach "Meier" sucht, und in der Liste gibt es nur "Meier ",
dann hätte ich Verständnis dafür, wenn die Funktion #NV zurückgibt, oder
auch noch, wenn sie "Meier" und "Meier " unter bestimmten Bedingungen
gleichsetzen würde (obwohl das auch nicht wirklich korrekt wäre). Aber
wenn sie dann "Lübke" zurückgibt, ist das definitiv ein Fehler, und zwar
einer, der größer gar nicht sein kann, v.a. in Hinblick auf seine
Auswirkung.
Wer
auf die Funktion angewiesen ist, sollte sich besser nach etwas anderem
umsehen,NAK; wer auf die Funktion angewiesen ist, sollte sie einfach nur korrekt
benutzen.
Die Benutzung /ist/ korrekt, und dennoch treten all diese Fehler auf.
Das wird Dir nix nützen; der Fehler sitzt /vor/ dem Bildschirm, nicht
dahinter.
Setz Dich noch einmal in Ruhe hin und überdenke, vor welchem Bildschirm
der Fehler gerade sitzt.
Tief durchatmen, und den Fehler bei *Dir* suchen statt bei *anderen*.
Nach tagelangem Suchen finde ich haufenweise Fehler nur bei dieser
Funktion. Dummerweise ist sie die mit Abstand am häufigsten von mir
verwendete. Und in anderen Office-Paketen, selbst in früheren Versionen
konnte man sich auf die korrekte Funktion blind verlassen, da hat das
noch funktioniert. Früher™ war eben doch alles besser... 
Hint: Es gibt verschiedene Möglichkeiten, um Schreibfehler sichtbar zu
machen. Mit am einfachsten ist die bedingte Formatierung ("Format =>
bedingte Formatierung => [X] Bedingung 1 => 'Formel ist' =>
ISTFEHLER(SVERWEIS(B2;$Tabelle2.$A$2:$B$50;1;0)) => Neue Vorlage =>
Hintergrund = Rot" o. ä.). Eine andere wäre, mit "Daten => Gültigkeit"
zu arbeiten (das hilft aber leider nur gegen /neue/ Fehler, nicht gegen
bereits vorhandene).
Das setzt voraus, dass die Funktion Fehler auch erkennt und meldet,
statt einfach nur falsche Werte zurückzugeben.
Hat denn jemand die aktuelle Version (ggf. Beta) unter Linux in Betrieb
und kann mir sagen, ob der Fehler da noch existiert? Das würde mir u.U.
einige Installations- und Rückkehrarbeiten ersparen helfen. Einfache
Prüfung geht mit meiner Datei, bei der in der Tabelle4 in Zelle D2 der
Wert #NV oder 1157,03 stehen muss; wenn da 585,67 steht, besteht der
Fehler weiterhin.
Hier ist die Datei:
http://www.kirk.de/files/2016-03-13_SVERWEIS-Test.ods
Hallo Boris, @ll,
leider kann ich - mangels bisheriger Nutzung - überhaupt nicht
beurteilen, wo der/die Fehler liegen könnten.
Ich habe hier derzeit die 5.0.5.2 unter Debian im Einsatz.
...
Hat denn jemand die aktuelle Version (ggf. Beta) unter Linux in Betrieb
und kann mir sagen, ob der Fehler da noch existiert? Das würde mir u.U.
einige Installations- und Rückkehrarbeiten ersparen helfen. Einfache
Prüfung geht mit meiner Datei, bei der in der Tabelle4 in Zelle D2 der
Wert #NV oder 1157,03 stehen muss; wenn da 585,67 steht, besteht der
Fehler weiterhin.Hier ist die Datei:
http://www.kirk.de/files/2016-03-13_SVERWEIS-Test.ods
Wenn ich die Datei öffne, steht in Tabelle4 in Zelle D2 der Wert 585,67.
Viele Grüße
Irmhild
Hallo,
Hallo,
...
Hat denn jemand die aktuelle Version (ggf. Beta) unter Linux in Betrieb
und kann mir sagen, ob der Fehler da noch existiert? Das würde mir u.U.
einige Installations- und Rückkehrarbeiten ersparen helfen. Einfache
Prüfung geht mit meiner Datei, bei der in der Tabelle4 in Zelle D2 der
Wert #NV oder 1157,03 stehen muss; wenn da 585,67 steht, besteht der
Fehler weiterhin.Hier ist die Datei:
http://www.kirk.de/files/2016-03-13_SVERWEIS-Test.ods
es ist definitiv der letzte Parameter, der auf 0 stehen muss - sonst nimmt Calc, falls der Suchbegriff nicht gefunden wird, den nächstbesten und nie #NV. Hab deine Tabelle gerade mit Excel 2016 ausprobiert - es liefert die gleichen Ergebnisse wie Calc.
Ich hab jetzt noch die Leerzeichen rausgelöscht und sehe kein Problem mehr?
Hier noch die bearbeitete Datei (LO 5.1.1.3 unter Win 7):
https://dl.dropboxusercontent.com/u/3483911/LO-divers/2016-03-13_SVERWEIS-Test.ods
MfG Alois
Hallo Boris
Hast du irgendetwas von dem gelesen und verstanden was Wolfgang schrieb??
…
Prüfung geht mit meiner Datei, bei der in der Tabelle4 in Zelle D2 der
Wert #NV oder 1157,03 stehen muss; wenn da 585,67 steht, besteht der
Fehler weiterhin.
Der Fehler sitzt weiterhin vor *deiner* Tastatur
Hier ist die Datei:
http://www.kirk.de/files/2016-03-13_SVERWEIS-Test.ods
Aber leider steht in der *gewollten* Suchzelle in Tabelle2 nicht "Meier" sondern "Meier " mit Leerzeichen, daher gibt dir der sortierte SVERWEIS auch den Wert aus der vorherigen Zeile zurück genauso wie das vorgesehen ist für SVERWEIS auf sortierten Suchmatrizen, falls der Suchbegriff nicht exakt so vorhanden ist.
Verwende einfach in solchen Fällen mal das 4.Argument 0 in deinen SVERWEISEN.
Werner
Hallo,
Ich hab jetzt noch die Leerzeichen rausgelöscht und sehe kein Problem mehr?
die Eingangsdaten zu verändern ist keine Lösung.
wenn man auf einen exakten Vergleich testet, dann schon
sonst müsste man eine Funktion (z.B. GLÄTTEN) nehmen, die die führende und nachfolgende Leerzeichen vor dem Vergleich entfernt.
Hallo Boris
[Antworten bitte an die Liste, nicht privat]
Hallo,
Aber leider steht in der *gewollten* Suchzelle in Tabelle2 nicht "Meier"
sondern "Meier " mit Leerzeichen, daher gibt dir der sortierte SVERWEIS
auch den Wert aus der vorherigen Zeile zurück genauso wie das vorgesehen
ist für SVERWEIS auf sortierten Suchmatrizen, falls der Suchbegriff
nicht exakt so vorhanden ist.wenn das so vorgesehen sein sollte (was ich bezweifle), dann wäre diese
"Vorsehung" falsch. Ein falscher Wert darf unter keinen Umständen
zurückgegeben werden. Wenn es wenigstens ähnlich wäre -aber was hat
"Lübke" mit "Meier " zu tun? Nee, das geht gar nicht.
Du magst das bezweifeln so lange du willst, es ist so vorgesehen und sinnvoll. ( und für Excel, Staroffice, && seit mindestens 15 Jahren so implementiert )
Wenn du nach "Meier" suchst und es auch einen "Meier" ohne sinnlose Leerzeichen in der Suchmatrix gibt, wird auch das gewünschte zurückgegeben.
Verwende einfach in solchen Fällen mal das 4.Argument 0 in deinen
SVERWEISEN.Dann bekomme ich mehr (falsche) Fehlermeldungen als Treffer.
Das sind dann *richtige* Fehlermeldungen und keine *falschen*
Werner
Hallo,
die Eingangsdaten zu verändern ist keine Lösung.
wenn man auf einen exakten Vergleich testet, dann schon
nein, das ist es grundsätzlich nie. Wenn eine exakte Suche dann nichts
findet, meldet sie genau das, und nicht irgendeinen anderen Wert, den
sie zufällig irgendwo anders findet.
sonst müsste man eine Funktion (z.B. GLÄTTEN) nehmen, die die führende
und nachfolgende Leerzeichen vor dem Vergleich entfernt.
entfernt GLÄTTEN() nicht auch Leerzeichen innerhalb der Zeichenkette?
Der Hilfetext lässt mich das vermuten.
Hallo,
Kein Wunder, wenn Du einen falschen Parameter benutzt. Ich zitiere mal
aus der Hilfe (die entscheidende Passage hab ich hervorgehoben):ich habe ihn keineswegs falsch benutzt, und das ist auch nicht der
Fehler. Vielmehr zeigt die Verwendung des Parameters, dass in der
Funktion gleich zwei Fehler vorliegen.
Lies doch bitte nochmal den von mir aus der Hilfe gequoteten Text;
und/oder den Text in der Hilfe direkt.
Zunächst: die Liste, die durchsucht wird, ist sortiert.
Das mag sein; aber wenn Du die Liste als 'sortiert' angibst, dann wird
laut hilfe und auch meiner Erfahrung nach *immer* ein Wert zurück
gegeben (und zwar der Wert vor dem ersten nächsthöheren Wert). Nur wenn
Du die Liste als 'unsortiert' angibst, sucht die Funktion nach der
exakten Entsprechung, und gibt einen Fehler aus, wenn der nicht
vorhanden ist.
Du kannst noch so sehr darauf bestehen, dass dieses Verhalten fehlerhaft
sei, aber es ist genau das Verhalten, das der dokumentierten
Beschreibung entspricht.
Somit müsste die
Funktion mit beiden möglichen Werten die richtige Zeile finden. Je nach
Konstellation findet sie aber entweder nichts oder die falsche Zeile
(!). Auch wenn man die Sortierung bricht, wird es nicht besser, denn
dann findet die Funktion mitunter nur noch eine Minderzahl der Einträge,
die vorhanden sind. Zusammen mit den schon früher beschriebenen
Fehlfunktionen, wenn die Liste sich in einer anderen Datei befindet,
kann ich nicht anders als die Funktion als mindestens nahezu unbrauchbar
kaputt zu bezeichnen.
Na gut, wenn Du das meinst, dann bleibt mir eben nix anderes übrig, als
Dir zu empfehlen, OO zu deinstallieren und ein anderes Programm zu
benutzen, oder notfalls sogar auf Papier und Bleistift zurück zu gehen.
Und daran kannst Du auch ganz klar erkennen, dass da irgend ein
Schreibfehler vorliegt. Wo genau liegt Dein Problem?Man könnte jetzt sagen, dass in den Daten ein Schreibfehler vorliegt.
Aber dann sollte die Funktion auch korrekt darauf reagieren.
Tut sie doch; sie reagiert genau so, wie in der Hilfe beschrieben.
Wenn also
die Funktion nach "Meier" sucht, und in der Liste gibt es nur "Meier ",
dann hätte ich Verständnis dafür, wenn die Funktion #NV zurückgibt, oder
auch noch, wenn sie "Meier" und "Meier " unter bestimmten Bedingungen
gleichsetzen würde (obwohl das auch nicht wirklich korrekt wäre).
Tut sie bei Sortierreihenfolge=0 auch; genau wie in der Hilfe beschreiben.
Aber
wenn sie dann "Lübke" zurückgibt, ist das definitiv ein Fehler,
Nein; der gefundene Wert "Meier " ist definitv *größer* als der gesuchte
Wert "Meier", denn es hängt da ja noch ein weiteres Zeichen dran. Und in
dem Fall gibt die Funktion definitionsgemäß bei Sortierreihenfolge=1
/den/ Wert zurück, der *vor* diesem größeren Wert steht; und das ist in
dem Fall eben "Lübke".
RTFM.
Wer
auf die Funktion angewiesen ist, sollte sich besser nach etwas anderem
umsehen,NAK; wer auf die Funktion angewiesen ist, sollte sie einfach nur korrekt
benutzen.Die Benutzung /ist/ korrekt, und dennoch treten all diese Fehler auf.
Ok, ja, stimmt; die Benutzung ist korrekt, denn Du hast die richtige
Anzahl Parameter benutzt, und auch die richtigen Typen, und sogar
zulässige Werte.
Aber *sinnvoll* ist sie nicht. Die Option Sortierreihenfolge=1 macht
doch überhaupt nur bei Zahlen Sinn, aber nicht bei Texten (selbst wenn
diese zufälligerweise trotzdem sortiert vorliegen sollten). Wenn Du zum
Bleistift die Textwerte "Anton", "Berta", "Cäsar" und "Emil" hast, dann
wird Dich bei der Suche nach "Dora" nur in den seltensten Fällen "Cäsar"
als Antwort interessieren. Wenn Du dagegen bleistiftsweise die
Zahlenwerte 2, 4, 6 und 8 hast, dann kann es bei der Suche nach 7 unter
Umständen(!), d. h. auch nicht immer, durchaus Sinn machen, wenn Du dann
eben die 6 erhältst.
Wenn Du das nicht einsehen *willst*, dann kehre eben zurück zu Papier
und Bleistift; dann ist Dir einfach nicht zu helfen. Sorry. EOD.
Tief durchatmen, und den Fehler bei *Dir* suchen statt bei *anderen*.
Nach tagelangem Suchen finde ich haufenweise Fehler nur bei dieser
Funktion.
"Achtung, auf der Autobahn kommt ihnen ein Geisterfahrer entgegen."
"Einer? Hunderte!"
Wolfgang
Hallo Boris,
entfernt GLÄTTEN() nicht auch Leerzeichen innerhalb der
Zeichenkette? Der Hilfetext lässt mich das vermuten.
Einfach austesten. Es werden alle Leerzeichen vor und hinter dem Text
entfernt, außerdem noch mehrfach hintereinander eingegebene
Leerzeichen innerhalb eines Textes auf ein Leerzeichen zusammengestaucht
.
Diese Funktion verhält sich etwas anders als die, die z.B. unter der
Bezeichnung "Trim" im Makrobereich üblich ist. Dort werden nur
führende und am Schluss liegende Leerzeichen abgeschnitten. Dort gibt
es dann auch noch RTrim und LTrim für linkes und rechtes Abschneiden.
Alles in Calc so nicht zu finden. Und wenn ich die Oberfläche von LO
auf Englischsprachig umstelle, dann verbirgt sich hinter GLÄTTEN() ...
TRIM().
Gruß
Robert