Suchfunktion fehlerhaft ??

Ich gebe zu, das ist verwirrend. Allerdings ist dieses Verhalten nur bei den Beträgen so. Bei Eingabe von 296 werden Datensätze mit ein Betrag 296,00 und auch -296,00 angezeigt, Datensätze mit 296,10 oder 296,11 nicht. Datensätze, bei denen im Verwendungszweck 296 vorkommt, werden angezeigt. Wenn also irgendo ein EC251942961234 auftaucht, dann wird das angezeigt. Somit reagiert die Suche zweigeteilt, bei Texten sucht sie das Vorommen von Teilstrings, bei Beträgen wird nur der GENAUE Betrag gefunden. Wenn man's weiß, kann man damit eine Menge machen, wenn man's nicht weiß, kann man lange rumsuchen.

Das, was Du gemacht hast, würde ich allerdings nicht über diese obige Generalsuche machen. Diese sucht offenbar nur noch in den Umsätzen, wenn ich mich recht erinnere, dann suchte die früher auch in Zahlungsaufträgen und Vorlagen und Begünstigten... bin mir aber nicht mehr sicher. Jedenfalls ist für Deine Belange sicher die Filtersetzung unter der Umsatzanzeige besser geeignet. Dort kannst Du einen Betragsbereich a la "Ausgaben zwischen 290 und 300" setzen und ggf. noch weitere Einschränkungen über Zeit und Text. Damit fidest Du das Gesuchte auf jeden Fall, auch wenn Du den Centanteil des Betrages nicht genau kennst.

Unten gehen nur GANZE Zahlen und nur Bereiche. Für 1589,69 müßtest Du also "von 1589 bis 1590" eingeben.

Wenn Du "oben zusätzlich" den genauen Betrag eigibst, dann übernimmt die obige Generalsuche und deaktiviert die untere Filterfuntion. Somit findest Du da den Betrag dann doch.

Und ja, mir erschließt sich der Sinn hinter dem Ganzen auch nicht wirklich völlig. Ich nehme an, daß das letztendlich mit dem historischen Wachsen des Programms zu tun hat...

Das ist jetzt die technische Erklärung, die auch einleuchtet. Der "Normalnutzer" wird da nie draufkommen und sich dann so wundern wie Salorian.

Dumme Frage: Wäre es nicht möglich, stattdessen die Beträge in Dezimaltext zu wandeln und dann den Suchstring damit zu vergleichen? Wahrscheinlich eine Frage der Performance? Wobei dieser Dezimaltext in vielen Fällen ja schon vorhanden ist, für die Anzeige... Für den Normalnutzer wäre das wahrscheinlich logischer...

Hallo,

@Salorian Gib mir bitte nur ein einziges Beispiel einer Software welche Datensätze mit Dezimalwerten in großen Mengen verarbeitet und bei der eine Suche nach dem Betrag "123" auch einen Treffer bei dem Wert 541234,98 liefert? Nur ein einziges.

@salorian: Du schreibst völlig am Thema vobei, da Du offenbar den technischen Hintergrund nicht verstanden hast. Der ist:

In der Datenbank liegen die Zahlen in Form einer binären Codierung vor - also einer Folge von Nullen und Einsen - und eben nicht in Form von Ziffernstrings. Jedes Mal, wenn die Zahl dem Menschen präsentiert wird, muß sie in den Ziffernstring gewandelt werden. Dies passiert zwar bei der Anzeige auf dem Bildschirm - aber eben nur für die gerade angezeigten Datensätze. Wenn man blättert, dann für die nächsten nötigen Datensätze.

Bei der Suche passiert nun folgendes: Der eingegebene Suchstring wird erstens mit den Texten verglichen (die Texte liegen als Textstrings vor, somit ist der Vergleich sofort möglich). Weiterhin wird der Suchstring, wenn er einen Zahlenwert darstellt, in die binäre Darstellung umgewandelt (EIN Mal) und diese Binärdarstelliung mit den Binärdarstellungen in der Datenbank verglichen - mit allen vorhandenen Datensätzen aller Konten. Das ist wohl noch halbwegs performant machbar. Wenn man es anders machen würde, dann müßte man beim Suchen von JEDEM Datensatz die Binärdarstellung des Betrages in einen Zahlenstring umwandeln, vergleichen und dann den Datensatz hernehmen oder verwerfen. Hier würde dann gerade bei großen Datenmengen die Performance massiv einbrechen.

Im Falle meines größten Tresores, der derzeit 97.000 Umsätze beinhaltet, wären also 97.000 zusätzliche String-Konversionen nötig. Du kannst Dir vorstellen, daß das dann zu einer argen Trägheit des Programms bzw. der Suchfunktion führen würde, bis dahin, daß die Suchfunktion nicht mehr sinnvoll verwendbar ist (man gibt eine Ziffer ein, es wird konvertiert und gesucht, bis das fertig ist friert das Programm ein, dann gibt man die nächste Ziffer ein, es wird wieder konvertiert und gesucht usw.). Insofern ist das durchaus sinnvoll, wie es jetzt ist. Wenn man eine Zahl sucht, zu der man den Cent-Anteil nicht kennt, kann man das genausogut über einen Betragsfilter von/bis machen, also z.B. 598,43 wird gefunden bei Filger von 598 bis 599. Auch über alle Konten ist dieser Filter möglich. Somit vermißt man nichts und hat oben eine performante Suche für andere Notwendigkeiten.

Ich muß sagen, ich bin eh sehr erstaung, WIE performant die Anwendung ohne große Datenbanken und Drumherum ist, wenn ich meinen größten Tresor mit 350 Konten und 97.000 Umsätzen anschaue. Dafür ganz großen Respekt an Andreas!

Kurz gesprochen: Weil das alles als TEXT vorliegende Strings sind und in dieser Anwendung die Suche so optimiert wurde, wie ich geschrieben habe. Sie ist nicht in erster Linie für eine Betragssuche gemacht, sondern für eine Textsuche. In Textform vorliegende Teile werden ja auch so durchsucht, wie Du es oben geschrieben hast Aber nim Binärformat vorliegende Zahlen sind eben nun mal kein Textstring. Alternative für eine "Benutzerverständlichkeit" wäre, den Betrag bei der Suche ganz wegzulassen und nur die Texte zu durchsuchen.

Für eine Betragssuche gibt es den dafür optimierten Filter. Ob Du das jetzt verstehst oder nicht, ändert daran (leider) auch nichts. Die Programmfunktion ist entsprechend durchdacht und optimiert und für verschiedene Problemstellungen gibt es verschiedene Lösungen im Programm. Das ist so und wird so bleiben. Somit gilt wie so oft im Leben: Friß oder stirb

Warum soll Andreas an einer Stelle etwas performanceraubendes (immer doppelt so viele Vergleiche wie derzeit, auch wenn man das garnicht braucht oder will) einbauen, wenn es genau das an anderer Stelle bereits gibt und man es dort gezielt nehmen kann? Wieso muß man unbedingt die EINE Suche hernehmen, wenn die ANDERE Suche das Mittel der Wahl ist? Kann ich nicht einsehen... Die Von-/Bis-Suche GIBT es ja über Filter bereits. Warum kann man die nicht einfach hernehmen und gut is? Dort kann man auch zusätzlich noch einen Textfilter angeben und zusätzlich noch einen Datumsfilter. Man kann gezielt das machen, was man braucht.

Ja, es sei denn, man will mit dem Kopf durch die Wand

@msa

erstmal war es einen Idee keine Forderungen.
desweiteren ging es drum, wie man das bestehende mit den Wünschen des Users verbinden kann = Kompromiss/Schnittmenge - egal wie es nennen willst.
dies hat auch den Nebeneffekt, dass solche Erklärungen/Diskussion wie hier und dessen dass der Anwender es sodann evtl. doch nicht versteht/verstehen will - aus bleiben.

abschließend wird bei der Idee doch keine performanceraubende Änderung vorgenommen, sondern wie vorgenannt nur bestehendes verwendet.


du solltest vielleicht auch mal, neben den Fakten, dich auf die Umstände einlassen und dann auch Lösungen probieren zu ermitteln/finden - das fällt dir anscheinend schwer.
(bei dem Pseudo-Update warst auch erst vehement dagegen und später hast es sogar in einem deiner letzten Postings aufgeführt)

ich hab anscheinend die Idee nicht richtig/verständlich darlegen können, denn sonst würdest du mit der Performance nicht kommen.

Basis-Idee eine "if then"-Abfrage in der Suche einzubinden: (das kennst du doch von excel)

- wenn Betrag vollständig (also 100,00) eingegeben = verfahre mit Suche wie bisher
- wenn Betrag unvollständig (also 100) eingegeben = dann geh zu Filter und befülle von <> bis (+1) - hier also von 100 bis 101


Dh. es müsst lediglich die "if then"-Abfrage gemacht werden, alles andere ist vorhanden mit gleicher Performance (also keinerlei Einbuße), da an der ja nichts geändert wird, ebensowenig wie an der Oberfläche.
Aber der User würde ein Ergebnis bekommen, ohne sich den Kopf zu zerbrechen warum das auf die eine Weise geht und nicht auf die andere
Hoffe jetzt ist es verständlicher was ich meine und selbst wenn wir nun einer/keiner gleichen Meinung wären - Andreas müsste es ja umsetzen oder eben auch nicht.