Vielleicht einfach mal das Konzept überdenken? Oder den Anwendern erklären, dass sie entweder 20-30 Sekunden warten müssen, wenn sie die gewohnte Bedienung nicht ändern wollen?
Du steckst jetzt viel Zeit in deine ganzen Überlegungen und Klimmzüge. Manchmal muss man dem Anwender auch mal zumuten, dass sich was ändert.

Ich hatte vor Jahren etwas ähnliches.
Mit den Datenmengen war die Bedienung nicht akzeptabel. Also habe ich das Lookup nachgebildet, aber etwas umgesetzt, was du auch schon angedeutet hast. Erst ab einer gewissen Anzahl an Buchstaben werden überhaupt Daten geholt. Zusätzlich habe ich die Pausen zwischen den Tastenanschlägen geprüft und erst, wenn offensichtlich nichts mehr getippt wird, die DB-Abfrage angestoßen. Die Kombination dieser beiden Dinge hat sehr gut funktioniert. Bei mir waren es mindestens 3 Zeichen und die Pause größer als 300 Millisekunden, wenn ich mich richtig erinnere.
Also einfach mal dein Standard-Lookup rausschmeißen und was eigenes programmieren. Was ich damals gebastelt hatte, war nicht wirklich kompliziert. Außerdem spart man sich auf diese Weise auch noch die Hintergrundprüfung, ob die Daten aktualisiert werden müssen. Der lokale Rechner und das Netzwerk werden vermutlich auch nicht mehr so stark belastet. Das hängt natürlich auch von den Daten ab, die dort vorliegen.

P.S.:
Ich gehe mal davon aus, dass du eine vernünftige Indexierung auf den Such- und Sortierfeldern hast.

In der Steuerungstechnik nennt man das 'entprellen'. Das geht mit einem Timer sehr einfach: Den Timer auf 300ms einstellen und bei jedem Tastendruck im Suchfeld (OnKeyUp) neu starten. D.h. solange man tippt, passiert nichts. Erst wenn man nicht tippt, wird automatisch nach 300ms der Timerevent aufgerufen der als erstes den Timer selbst deaktiviert und dann prüft, ob man die Daten nachladen kann/muss (Length>3 o.ä.)

Diesen kleinen Trick kann man immer dann verwenden, wenn man implizit etwas nachladen muss. So habe ich eine Report-Preview gebaut: Eine lange Liste von Reports wird im Grid angezeigt und daneben die Preview. Wenn man im Grid die Zeile wechselt, wird der entsprechende Report angezeigt. Beim Scrollen würde sich der PC aber einen Wolf rendern und das ganze ruckelt doch ganz schön: Also diesen Timer eingebaut und Ruhe im Karton. Billiger Trick, aber sehr effektiv.

Ich verwende MsSQL. Wenn die Daten mal geladen sind, ist ein Schnelltipper immer noch behindert. Ich habe aber gefragt was den Anwendern lieber ist "Daten sofort zu sehen" oder "Schneller tippen zu können" und die Mehrzahl ist für Daten sehen, Kritikpunkt ist eigentlich nur die Ladezeit. Und der Plan war eben, die Daten im Hintergrund zu laden und dann zu aktivieren und danach nur noch die Änderungen zu aktualisieren.

Zitat:

Manchmal muss man dem Anwender auch mal zumuten, dass sich was ändert

Das ist genau die Einstellung, die ich den meisten Programmierern vorwerfe. Sie denken, die Welt dreht sich um sie, dabei dreht sie sich um die Anwender. Ich bin eben der Meinung es ist einfacher ein Programmierer steckt etwas Gehirnschmalz in ein Problem als wenn sich zig User mit dem Problem rumschlagen (Oder auch nur ein User, der aber Tag für Tag). Und deshalb ist es eben einfacher ich stecke Zeit in ein Problem als dass sich die Anwender ärgern. Zumal ich gleichzeitig auch Anwender bin.
Als ich das Thema vor 5 Jahren mal diskutiert habe, hat jeder gemeint dass die Funktion im Zeitalter von SQL-Datenbanken keiner mehr braucht. Google-Sei-Dank wissen mittlerweile die meisten, dass es eben doch sinnvoll ist. Auch wenn der Programmierer nicht gleich eine Lösung hat.

Das mit der Zeitverzögerung hatte ich schon mal implementiert, das ist aber nicht so gelaufen wie ich wollte. Werde aber auch hier mal Zeit investieren. Wenn aber die Ladezeit reduziert werden kann, da der Prozess im Hintergrund läuft, wäre mein Problem schon wesentlich entspannt (Außer der Netzwerkler kommt und meint sein Netz sei überlastet)

Grüße
Gerd

Zitat von norwegen60:

Als ich das Thema vor 5 Jahren mal diskutiert habe, hat jeder gemeint dass die Funktion im Zeitalter von SQL-Datenbanken keiner mehr braucht. Google-Sei-Dank wissen mittlerweile die meisten, dass es eben doch sinnvoll ist.

Google ist ein gutes Beispiel. Die schaffen es, unmittelbar nach einem Tastendruck Suchvorschläge aus Milliarden(?) von Suchbegriffen zu machen, und das über eine popelige Internet-Leitung. Oder laden die sich etwa vorher ihren kompletten Index auf meinen Rechner?


Wenn die Daten trotzdem unbedingt komplett geladen werden sollen, würde ich mal überlegen, diese dann lokal zu speichern (und laden). Eine Update-Funktion willst du ja eh einbauen.

Zitat von norwegen60:

Zitat:

Manchmal muss man dem Anwender auch mal zumuten, dass sich was ändert

Das ist genau die Einstellung, die ich den meisten Programmierern vorwerfe. Sie denken, die Welt dreht sich um sie, dabei dreht sie sich um die Anwender.

Ich bin da völlig auf deiner Seite. Ich habe das vielleicht etwas ungeschickt ausgedrückt.
Es ging nur darum, dass man die gewohnte Bedienung verändert, damit es für den Anwender komfortabler wird. Andere (akzeptable) Bedienung mit mehr Geschwindigkeit.

Zitat von Olli73:

Google ist ein gutes Beispiel. Die schaffen es, unmittelbar nach einem Tastendruck Suchvorschläge aus Milliarden(?) von Suchbegriffen zu machen, und das über eine popelige Internet-Leitung. Oder laden die sich etwa vorher ihren kompletten Index auf meinen Rechner?

Google arbeitet mit einer ganz besonderen und – soweit mir bekannt – auch einmaligen Rechner-Verclusterung:

Ein weiteres Ergebnis der internen Entwicklungsarbeit ist das GOOGLE FILE SYSTEM (GFS), gewissermaßen das Nervensystem von GOOGLE. Grundlage für das GFS, das auf fast allen GOOGLE-Computern läuft, war das Quellcode-offene Betriebssystem Linux. Das GFS weiß, welche Informationen wo in dem riesigen Datenmeer liegen. Es steuert GOOGLEs riesige Computerverbände. Diese sogenannten Cluster bestehen aus einigen 100 oder sogar aus mehr als 5000 Computern. Das GFS hält sie zusammen. Fallen Rechner aus, fängt das System diese Pannen auf. Um Datenverluste zu verhindern, speichert das GFS jede Datei mindestens drei Mal. Selbst wenn der Betrieb nicht normal läuft, spürt das GFS in Windeseile die Daten aus dem Datenbestand auf, der geographisch am nächsten beim Nutzer liegt, oder von den Rechnern, die die meisten Ressourcen frei haben und damit am schnellsten arbeiten. Fallen ein paar Computer plötzlich aus, holt sich die Software die Daten einfach von einem der anderen Rechner.

Statt nach dem perfekten Computer zu suchen, gingen GOOGLEs Netzwerkingenieure immer davon aus, daß sich Hardware-Ausfälle ohnehin nicht vermeiden lassen. Sie versuchten erst gar nicht, besonders gute Computer zu konstruieren, sondern verwendeten ihren Einfallsreichtum darauf, Maschinen schnell aus dem Verbund heraustrennen und neue Rechner einbauen zu können. Entsprechend haben die Software-Ingenieure das GFS aufgebaut: »Es muß fortlaufend sich selbst überwachen und Komponentenausfälle entdecken, aushalten und sich schnell wieder von ihnen erholen«, schreiben sie in einem Fachartikel.

Quelle: Lars Reppesgaard, "Das Google Imperium – Google kennt dich besser, als du denkst", ISBN 978-3-86774-046-3, 2008 Murmann Verlag GmbH, Hamburg

1,2 Mio Datensätze auf Verdacht zu laden, weil gerade mal einige benötigt werden...

Wenn es sich dabei doch um Seriennummern handelt, die ja sowieso per Hand eigegeben werden, dann reicht es doch sicherlich aus, die benötigten Lookup-Daten erst zu holen, wenn die Anzahl der eingegeben Daten eine sinnvolle Vorauswahl zulassen (denn vorher blättert doch eh keiner) und damit die Datenmenge massiv einschränken.

Ansonsten mach es doch so, wie schon mit einem Timer vorgeschlagen:

Oder so.
Benutzer Tippt Zeichen
-> Thread starten um die Ergebnismenge erst mal zu holen
Tippt der Benutzer jetzt nächstes Zeichen, bevor der Thread beendet ist, dann
-> Thread abbrechen -> neuen Thread starten
usw.
Wenn aber Ergebnismenge zur Verfügung steht, bevor der Benutzer ein weiteres Zeichen eingegeben hat, dann kannst du ja die Ergebnismenge in dein Lookup kopieren.

Da der Benutzer eh auf die Ergebnismenge warten muss, wird er wahrscheinlich ein weiteres Zeichen eingeben, und dann brauchst du ja die vorherige Ergebnismenge nicht mehr, da sie Daten enthält, die eh nicht in Frage kommen.
Ich habe leider keine 1,2 Mio. Datensätze zur Hand, sonst würde ich es ausprobieren. Aber ich könnte mir gut vorstellen, dass es so ohne lästige Eingabepause recht flüssig laufen könnte.

Zitat von norwegen60:

Ich verwende MsSQL. Wenn die Daten mal geladen sind, ist ein Schnelltipper immer noch behindert.

Wie meinst Du das? Wie, wann ist ein 'Schnelltipper' behindert?

Ich kenne aber das Problem: Inkrementelle Suche 'while you type' ist schon charmant. Da dabei sehr viele -ziemlich bescheuerte- Abfragen an den SQL-Server gestellt werden, ist eine im-Memory Suche hier wirklich richtig.

Ich habe dafür einen Dienst geschrieben, der die Daten beim Hochfahren lokal auf den Client-PC saugt und auch die Aktualisierung vornimmt. Der Client (also die Anwendung) redet über COM mit dem lokalen Dienst, um die Filterung vorzunehmen. Ich zeige auch nur die ersten 1000 Records an, weil durch die scrollt eh keine Sau. Aber die 'Suchzeiten' sind im Bereich von < 20ms pro Tastendruck, also brauche ich noch nicht einmal die Entprellung.

Durch das Laden der Daten beim Rechnerstart entfällt auch die lange Wartezeit beim Start des Programms.

Allerdings ist das Suchen in 1.2 Mio DS in wenigen Millisekunden nicht trivial, vor allen Dingen bei den ersten paar Zeichen. Aber da gibt's auch Tricks.

Hallo,

2 Monate später
Auch ich wurde schon einige Male "gezwungen" alle Daten clientseitig zu laden so dass der Anwender in zig Millionen Datensätzen suchen kann...

Ich habe gerade mal mit einer In-Memory-Testumgebung in Form einer TStringList() getestet.
Folgende Bedingungen:
Suchwort = 3 Zeichen
Suchstring pro Zeile = 70 Zeichen lang

Bei 3 Mio Datensätzen (= 27,3 MB RAM) benötigt die Standardsuche mit Pos() ca. 977ms.
Ich vermute, dass meine ausgesuchten Bedingungen nicht so gut sind wie deine, von daher wird wahrscheinlich diese Suche auf deine Ergebnismenge angewendet noch einiges schneller sein. Wenn du nur nach Zahlen suchst wird die Suche nochmals geschätzte 6-10x schneller sein.

Bei 1,2 Mio Datensätzen (= 13,4 MB RAM) benötigt mein Test 391 ms. Wenn man die schon genannten Such-Bedingungen berücksichtigt (Timer-Event über 300ms beim Tastendruck und erst nach 3 Zeichen suchen lassen), scheint eine einfache In-Memory-Suche ausreichend, oder?

Mittlerweile habe ich mit der Volltextsuche von Microsoft sehr gute Ergebnisse erzielt. Dabei ist die Suchgeschwindigkeit bei > 10 Mio Records im Bereich von 100ms. Natürlich, ohne die Daten vorher in den Speicher zu laden.

Wenn man dann noch Pagination einsetzt, ist man dann schon ziemlich nahe an Google

Auch über das Internet.

Der 'Nachteil' der Volltextsuche ist hier imho gleichzeitig ein Vorteil. Man kann nur nach Wortanfängen suchen. "Delp*" findet "Delphi", aber "*elphi" findet gar nichts. Dafür ist eine Synonymliste, Verbreflexion etc. schon eingebaut. Wer will, kann 'Meyer', 'Maier', 'Mayer' und 'Meier' zusammenfassen.