String in TStringList finden verschnellern?

[a.def]

In meinem Programm werden zwei StringListen mit mal mehr, mal weniger Einträgen erzeugt. Das kann bis in die Tausende und Zehntausende, auch Hunderttausende gehen.

Ich prüfe an einer bestimmten Stelle, ob ein Eintrag X aus Liste 1 in Liste 2 vorhanden ist. Das mache ich so

Delphi-Quellcode:

// Beispiel:
// sTmp ist 'C:\1\2\3\4.txt';
// List enthält ("Liste 2)
// - C:\1.txt
// - C:\1\2.txt
// - C:\1\2\3.txt
// - C:\1\2\3\4.txt

function IndexOfListObjects(const sTmp: string; List: TStringList): Integer;
begin
 for Result := 0 to List.Count - 1 do
  if sTmp = PFileListEntry(List.Objects[Result])^.sFileName then
   Exit;

 Result := -1;
end;

So speichere ich zuvor in die Liste wenn diese erstellt wird

Delphi-Quellcode:

// Record erzeugen mit New()
// ...
List.AddObject(aFileListEntry.sFileName, Pointer(aFileListEntry));

PFileListEntry ist ein Rekord mit ein paar Informationen wie Dateiname und Attributen usw.

Diese Prüfung "IndexOfListObjects" wird bei jeder Iteration von "Liste 1" durchgeführt.
Das dauert relativ lange. Kann man das nicht irgendwie verschnellern?

[nahpets]

Ist die Liste sortiert?

Wenn ja, versuch' es mal mit 'ner binären Suche.

Kannst Du die Liste sortieren?
Wenn ja, wie lange dauert das?

Wäre ggfls. ein Sortieren der Liste und dann anschließend eine binäre Suche insgesamt schneller als Dein bisheriges Vorgehen?

Was steht in der Stringliste selbst drin?
Du suchst ja in den Objekten.
Könnte eine Suche mit List.IndexOf(sTmp) ggfls. schneller sein, sofern Du dort bereits einen sinnvoll zu suchenden Inhalt haben solltest?

Wenn als Beispiel in

Delphi-Quellcode:

PFileListEntry(List.Objects[0])^.sFileName

Delphi-Quellcode:

C:\1\2\3\4.txt

stehen würde, was stände dann in

Delphi-Quellcode:

List[0]

?

[Fritzew]

Hallo

da Du ja den Filenamen schon in der Liste stehen hast

Delphi-Quellcode:

List.AddObject(aFileListEntry.sFileName, Pointer(aFileListEntry));

Könntest Du doch einfach mit

Delphi-Quellcode:

result := List.indexof(sTemp) danach suchen

Wenn Die Liste dann auch noch sortiert ist geht das relativ schnell

ansonsten benutze doch ein Dictionary

[a.def]

Zur Beantwortung deiner Fragen:

- die Liste war nicht sortiert. Ich habe nun nach dem Create der Liste ein Sorted := True; angehangen.

- das Benutzen von IndexOf(sTmp) war deutlich langsamer als das Suchen in den Objekten.

Zitat:

Wenn als Beispiel in PFileListEntry(List.Objects[0])^.sFileName C:\1\2\3\4.txt stehen würde, was stände dann in List[0] ?

In List[0] wäre dann im besten Fall genau derselbe String.

[p80286]

Zitat:

Zitat von a.def (Beitrag 1358325)

Zur Beantwortung deiner Fragen:

- die Liste war nicht sortiert. Ich habe nun nach dem Create der Liste ein Sorted := True; angehangen.

in unsortierten Listen (Arrays etc.) suchen, ist grundsätzlich nicht empfehlenswert.

Zitat:

Zitat von a.def (Beitrag 1358325)

- das Benutzen von IndexOf(sTmp) war deutlich langsamer als das Suchen in den Objekten.

Das sollte aber der pure Zufall gewesen sein.

Statt

Delphi-Quellcode:

Indexof

könntest Du auch

Delphi-Quellcode:

Find

nutzen, oder aber wie Stefan schon vorgeschlagen hat, bau Dir eine Binäre Suche, die könntest Du dann für Deine speziellen Zwecke anpassen.

Gruß
K-H

[nahpets]

Ok, mit Sorted := True ist der Inhalt also aufsteigend sortiert und damit kannst Du dann binär suchen.

Grober Überblick: https://de.wikipedia.org/wiki/Bin%C3%A4re_Suche

Hier im Forum mal suchen: http://www.delphipraxis.net/dp_searc...ch_matchmode=0

@p80286
IndexOf ist nicht wirklich schnell, da es in unsortierten Listen letztlich auch in 'ner While-Schleife alle Einträge abfragt, bis was gefunden wurde.
Entspricht daher vom Zeitaufwand vermutlich in etwa der For-Schleife.

In 'ner sortierten Liste wird allerdings mit Find gesucht.

@a.def
Durch das Sorted := True könnte sich damit die Laufzeit für IndexOf verändert haben.

[himitsu]

IndexOf und Find sollte doch gleich schnell sein?
Und ja, sortieren hilft (Sorted=True), denn dann wird eine andere Suchmethode verwendet.
> TArray.BinarySearch

Alternativ eine HashList.
TDictionary?

[a.def]

Mich würde mal interessieren, warum eine sortierte Liste schneller durchsucht werden kann als eine unsortierte?
Ob da jetzt 1 Millionen sortierte oder unsortierte Einträge sind... es sind 1 Millionen. :?:

[DeddyH]

Weil man in einer sortierten Liste eben nicht mehr alle Einträge sequentiell durchsuchen muss. Schau Dir doch einfach einmal an, wie eine binäre Suche funktioniert ("Pieksen" in die Mitte, vergleichen und eine Hälfte ignorieren, das so lange, bis der gesuchte Eintrag gefunden wurde oder es keine "Mitte" mehr gibt -> kein Treffer).

[stahli]

Man fängt in der Mitte an und schaut, ob der Suchwert größer oder kleiner ist.
Je geht man zur Mitte der kleineren oder größeren Hälfte und dann weiter bis zum Treffer.
Dann erhält man nach einigen Zyklen das Ergebnis oder die Position, an der der neue Eintrag eingefügt werden müsste.

Das ist die binäre Suche.

[himitsu]

Das Tempo ist da logarithmisch und nicht linear.

* jeden Eintrag durchsuchen, also im Durchschnitt 50% aller Einträge, bis man was findet.
* die binäre Suche ist für Sortiertes optimiert, da man beim Vergleich sofort weiß, ob man was getroffen hat und wenn nicht, ob es vor oder hinter dem Eintrag zu finden ist

bei 1000 Einträgem
* linear = durchschnittlich 500 Vergleiche
* binär = maximal 10 Vergleiche


Zusätzlich noch CaseSensitive=True.
Dateinamen sind zwar CaseSensitive=False, aber wenn du außerhalb AnsiUpperCase/FileNameUpperCase machst, dann muß das die Liste nicht mehr bei jedem Eintrag machen.
Beim Dictionary gibt es auch welche, die CaseInsensitiv den Hash berechnen und das dann ebenfalls nicht mehr bei jedem Eintrag machen müssen, während der Suche.

[a.def]

Zitat:

Man fängt in der Mitte an und schaut, ob der Suchwert größer oder kleiner ist.

Das erinnert mich an ein kleines Spiel, welches ich zu Schulzeiten in Java geschrieben habe. Dabei ging es um das Erraten einer Zahl.

Nun habe ich es verstanden.

[himitsu]

Darum auch Binär (Zwei), weil man dort immer alles halbiert.

Die maximal nötigen Vergleiche, bis man einen Eintrag gefunden hat, sind auch "zufällig" immer Zweiterpotenzen.

...
65 bis 128 = maximal 7 Vergleiche
129 bis 256 Werte = maximal 8 Vergleiche
257 bis 512 Werte = maximal 9 Vergleiche
513 bis 1024 Werte = maximal 10 Vergleiche
...

[mjustin]

Wäre eine Lösung mit TDictionary (Generics.Collections) nicht wesentlich schneller, wenn die Anzahl wie angegeben in die Hunderttausende geht?

[himitsu]

Wurde schon erwähnt.

TDictionary ist eine sortierte Hash-Liste mit binärer Suche.

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1358330)

In 'ner sortierten Liste wird allerdings mit Find gesucht.

Gleicher Aufruf, unterschiedliches Verhalten, das liebe ich.

Gruß
K-H

[a.def]

Was haltet ihr denn davon. Ist das eine Lösung?
Speeding Up Delphi's TStringList.IndexOf

Ich nutze nun

Delphi-Quellcode:

function IndexOfListObjects(const sTmp: string; List: TStringListEx): Integer;
begin
 // for Result := 0 to List.Count - 1 do
 // if sTmp = PFileListEntry(List.Objects[Result])^.sFileName then

 if not List.Find(sTmp, Result) then
  Result := -1;
end;

[himitsu]

Zitat:

Delphi-Quellcode:

function TStringList.IndexOf(const S: string): Integer;
begin
  if not Sorted then Result := inherited IndexOf(S) else
    if not Find(S, Result) then Result := -1;
end;

Wenn deine Liste also Sortiert ist, ergibt es das. :roll:

Delphi-Quellcode:

function TStringList.IndexOf(const S: string): Integer;
begin
  if not Find(S, Result) then 
    Result := -1;
end;

[a.def]

Einziger Unterschied den ich gerade erkennen konnte ist, dass die offizielle Fassung von Find () CompareStrings aufruft, die inoffizielle CompareStr().
Sonst ist alles gleich. Hätte ich mal vorher gucken sollen.

[haentschman]

Moin...8-)

Was ich nicht verstehe, das du dich gegen das angesprochene TDictionary, jedenfalls habe ich es nicht gesehen, wehrst... :gruebel: Das ist genau das für den Einsatzzweck gut ist... als das rumgeeiere mit der Stringlist... :roll:

[EmWieMichael]

Zitat:

Zitat von himitsu (Beitrag 1358343)

...
65 bis 128 = maximal 7 Vergleiche
129 bis 256 Werte = maximal 8 Vergleiche
257 bis 512 Werte = maximal 9 Vergleiche
513 bis 1024 Werte = maximal 10 Vergleiche
...

Täusche ich mich, oder werden bei dieser Rechnung die Vergleiche mit '=' vergessen? Ich muss doch nach jeder Halbierung zwei Vergleiche anstellen: '=' und ('<' oder '>').
Oder ist es mit 8 Uhr noch zu früh für mich...? :oops:

[a.def]

Zitat:

Zitat von haentschman (Beitrag 1358369)

Moin...8-)

Was ich nicht verstehe, das du dich gegen das angesprochene TDictionary, jedenfalls habe ich es nicht gesehen, wehrst... :gruebel: Das ist genau das für den Einsatzzweck gut ist... als das rumgeeiere mit der Stringlist... :roll:

Ich wehre mich doch nicht dagegen :P
Ich kenne es nur nicht.

Ist das in etwas so? http://www.delphipraxis.net/94559-ei...onary-map.html
Wenn ja, dann bedeutet das ja "doppelte Buchführung" wenn ich das richtig sehe. Denn man braucht einen linken und rechten Teil um ein Paar zu bilden.

[himitsu]

Zitat:

Zitat von EmWieMichael (Beitrag 1358370)

Täusche ich mich, oder werden bei dieser Rechnung die Vergleiche mit '=' vergessen? Ich muss doch nach jeder Halbierung zwei Vergleiche anstellen: '=' und ('<' oder '>').

Rein "logisch" nur eine mathematische Rechnung.

Delphi-Quellcode:

V = A - B

(gleich 0, kleiner 0, größer 0)
CompareValue
Dann weiß man sofort ob größer, kleiner oder gleich.

Aber aus diesem Grund sind Hash-Listen schneller, da dort je Wert nur ein "Vergleich" nötig ist, während bei Strings ja jedes einzelne Char verglichen werden muß.

Die genaue Anzahl der physischen Vergleiche, im Bytecode (Assembler) oder gar in der CPU, will man besser nicht wissen.
Für einen Vergleich zweier Suchalgorithmen reicht es, wenn man die ungefähre Anzahl der logischen Vergleichsoperationen kennt.

[a.def]

Bei einem ganz einfachen Test war bei mir die normale StringList schneller

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var
 sl: THashedStringList;
 i, X: Integer;
 Watch: TStopwatch;
begin
 sl := THashedStringList.Create;

 sl.Sorted := True;
 for i := 0 to 49999 do
  sl.Add(TStringUtils.RandomString(60));

 sl.Add('ABCABCABC');

 for i := 0 to 49999 do
  sl.Add(TStringUtils.RandomString(60));

 Watch := TStopwatch.Create;
 Watch.Start;

 for i := 0 to sl.Count - 1 do
  begin
   sl.Find('ABCABCABC', X); // Absichtlich kein Break, damit alles verglichen wird
  end;

 Watch.Stop;
 ShowMessage(IntToStr(Watch.ElapsedMilliseconds) + 'ms');
 sl.Free;
end;

// StringList: ~180ms
// HashedList: ~200ms

[himitsu]

Das liegt daran, dass du ausgerechnet die grausamste und sinnloseste Implementation einer Hashlist erwischt hast.

Delphi-Quellcode:

//Unit IniFiles

function THashedStringList.IndexOf(const S: string): Integer;
begin
  UpdateValueHash;
  if not CaseSensitive then
    Result := FValueHash.ValueOf(AnsiUpperCase(S))
  else
    Result := FValueHash.ValueOf(S);
end;

Vor jeder einzelnen Suchanfrage werden ALLE Hashs neu berechnet. :wall:
Das muß zwangsläufig langsamer sein.

[a.def]

Zitat:

Zitat von himitsu (Beitrag 1358380)

Vor jeder einzelnen Suchanfrage werden ALLE Hashs neu berechnet. :wall:

Wenn die HashedStringList mit diesem groben, sagen wir mal, "Fehler" diese geschwindigkeit erzielt (nur 20ms langsamer als die normale in meinem Beispiel), dann muss die ja super schnell sein, wenn dieser "Fehler" nicht ist.

Ich habe das jetzt mal mit IndexOf statt Find gemacht und da ist die HashedStringList schneller als die normale (trotz Neuberechnung der Hashes)

[haentschman]

Zitat:

Ist das in etwas so?

Nöö... :P

Schau mal hier: http://docwiki.embarcadero.com/Libra...ns.TDictionary

eine der Varianten...TryGetValue: http://docwiki.embarcadero.com/Libra...ry.TryGetValue
... gibt den Value zurück wenn Key gefunden wird.

[nahpets]

Wenn man in IndexOf und Find reinschaut, sieht man, dass da noch ziemlich vieles gemacht wird, um zum Vergleichsergebnis zu kommen.

Hier wird aber doch "nur" ein einfacher Vergleich auf Übereinstimmung von Zeichenfolgen in 'ner sortierten Stringliste benötigt.

Wie wäre es denn, hier einfach mal 'ne eigene Suchroutine zu schreiben, der die Stringliste übergeben wird und die als Rückgabewert den Index des gesuchten Eintrages der Stringliste liefert.

Ungetestet und nur hingedaddelt, daher ohne jegliche Garantie für irgendwas, sondern nur als Idee für's eigene Ausprobieren:

Delphi-Quellcode:

function BinSearch(Suche : String; Start : Integer; Ende : Integer; sl : TStringList) : Integer;
var
        Mitte : Integer;
begin
  Mitte := Start + ((Ende - Start) div 2);
  if Suche <= sl[Mitte] then Result := BinSearch(Suche, Start, Mitte, sl)
  else Result := BinSearch(Suche, Mitte, Ende, sl);
end;

Hier fehlt zum Beispiel noch die Prüfung, ob der Suchbegriff überhaupt in der Stringliste vorkommt, also ist

Delphi-Quellcode:

sl[BinSearch('ASDF',0,sl.Count - 1,sl) = 'ASDF';

Könnte daraus eventuell dann sowas werden?

Delphi-Quellcode:

function IndexOfListObjects(const sTmp: string; List: TStringList): Integer;
begin
 Result := BinSearch(sTmp,0,List.Count - 1,List);
 if List[Result] <> sTmp then Result := -1;
end;

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1358378)

Aber aus diesem Grund sind Hash-Listen schneller, da dort je Wert nur ein "Vergleich" nötig ist, während bei Strings ja jedes einzelne Char verglichen werden muß.

Naja nicht unbedingt, "damals" haben wir die Strings in 16-Bit Werte zerhackt, und diese dann verglichen, da konnte man gegenüber den 8-Bit Vergleichen knappe 50% herausholen. Mit 32-Bit oder gar 64-Bit kann man da gut Gas geben. Und die hash-Berechnung fällt nicht an.

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von nahpets (Beitrag 1358385)

Wenn man in IndexOf und Find reinschaut, sieht man, dass da noch ziemlich vieles gemacht wird, um zum Vergleichsergebnis zu kommen.

Insbesondere sieht man, daß

Delphi-Quellcode:

Find

eine binäre Suche durchführt und

Delphi-Quellcode:

IndexOf

direkt Find aufruft, wenn

Delphi-Quellcode:

Sorted

gesetzt ist.

Daraus folgt a) daß

Delphi-Quellcode:

Find

nur dann funktionieren kann, wenn

Delphi-Quellcode:

Sorted

gesetzt wurde, und b)

Delphi-Quellcode:

IndexOf

immer funktioniert c)

Delphi-Quellcode:

IndexOf

im Falle von

Delphi-Quellcode:

Sorted

wegen der binären Suche in

Delphi-Quellcode:

Find

schon recht schnell sein sollte.

Bleiben noch die Optimierungsmöglichkeiten in

Delphi-Quellcode:

CompareStrings

, das sowohl von

Delphi-Quellcode:

Find

als auch von

Delphi-Quellcode:

IndexOf

im Falle von

Delphi-Quellcode:

Sorted = false

aufgerufen wird. Da CompareStrings virtuell ist müssen wir hier die Implementierung in TStringList heranziehen. Darin wird je nach Kombination der Properties UseLocale und CaseSensitive CompareStr oder CompareText bzw. der Ansi-Pendants aufgerufen. Letztere bemühen jeweils eine Funktion aus der Windows-API und sind somit potentiell langsamer als ihre nativen Vettern. Diese beiden (CompareStr und CompareText) sind aus dem Fastcode-Projekt übernommen worden und somit potentiell auch nicht die langsamsten. Da die Text-Variante noch die Groß/Klein-Schreibung berücksichtigt (in dem sie sie ignoriert), ist diese potentiell noch etwas langsamer als CompareStr, daß einen direkten Vergleich durchführt.

Folglich sollte das beste Ergebnis erzielt werden, wenn die Stringlist mit folgenden Einstellungen betrieben wird:

Delphi-Quellcode:

Sorted := true;
CaseSensitive := true;
UseLocale := false;

Trotzdem kann das stumpfe Iterieren durch alle Strings mit einem direkten Vergleich durchaus deutlich schneller sein, als das Find. Im Gegensatz zu CompareString, daß einen Ordnungsvergleich (kleiner, gleich, größer) durchführt, wird bei einem direkten Vergleich eben nur auf Gleichheit getestet. Da Strings aber referenzgezählte Objekte sind, kann bei diesem Vergleich als erstes geprüft werden, ob es sich um dasselbe Objekt handelt und nicht nur um einen String mit demselben Inhalt.

Selbst bei mehreren Millionen Einträgen kann der Brute-Force Ansatz immer noch schneller sein. Man sollte das also mit realen Daten testen, bevor man blind eine bestimmte Methode einsetzt.

[a.def]

Das gibt einem zu denken. Danke für die ausführliche Erklärung!

Eine Frage habe ich noch. Wenn man sorted auf True setzt, ist das hinzufügen zur Liste deutlich langsamer und Einträge die schon vorhanden sind werden ignoriert.
Spielt es eine Rolle, ob ich Sorted vor oder nach dem Hinzufügen all meiner Einträge auf True setze?

[Fritzew]

Also:

Delphi-Quellcode:

sl := Tstringlist.create;
sl.Duplicates = dupAccept; // Damit Duplicate erlaubt sind
// Alles einfügen

// dann
sl.sorted := true;  // Sortiert die Liste

so sollte es gehen

[nahpets]

Wenn Sorted = true muss beim Einfügen geschaut werden, wo der neue Eintrag hin muss, damit er dort eingefügt werden kann.

Statt Sorted = true könntest Du mal probieren, ob der Aufruf von Sort vor der Stelle, ab der Du suchen willst, etwas bringt. Du muss dann aber an der Stelle mit etwas Wartezeit rechnen.

Man kann für den Fall dann auch eine eigene Sortierroutine zuweisen, die eventuell auch das Laufzeitverhalten ändern könnte.

[a.def]

Habe es nun testen können. Funktioniert einwandfrei, Sort; erst später aufzurufen und Sorted zu setzen (habe einfach beides gemacht).
Die Wartezeit für das "manuelle Sortieren" der Liste im Nachhinein mit dem Aufruf durch Sort; oder dem Setzen von Sorted := True ist sehr viel kürzer als die die entsteht, wenn man es bereits vorher so einstellt.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1358417)

Habe es nun testen können. Funktioniert einwandfrei, Sort; erst später aufzurufen und Sorted zu setzen (habe einfach beides gemacht).
Die Wartezeit für das "manuelle Sortieren" der Liste im Nachhinein mit dem Aufruf durch Sort; oder dem Setzen von Sorted := True ist sehr viel kürzer als die die entsteht, wenn man es bereits vorher so einstellt.

Delphi-Quellcode:

Sorted := true

ruft intern sowieso ein

Delphi-Quellcode:

Sort

auf, das nun aber nichts mehr verändert. Probier mal, ob es noch etwas schneller ist, wenn du den expliziten

Delphi-Quellcode:

Sort

-Aufruf weglässt.

[a.def]

Zitat:

Zitat von Uwe Raabe (Beitrag 1358421)

Zitat:

Zitat von a.def (Beitrag 1358417)

Habe es nun testen können. Funktioniert einwandfrei, Sort; erst später aufzurufen und Sorted zu setzen (habe einfach beides gemacht).
Die Wartezeit für das "manuelle Sortieren" der Liste im Nachhinein mit dem Aufruf durch Sort; oder dem Setzen von Sorted := True ist sehr viel kürzer als die die entsteht, wenn man es bereits vorher so einstellt.

Delphi-Quellcode:

Sorted := true

ruft intern sowieso ein

Delphi-Quellcode:

Sort

auf, das nun aber nichts mehr verändert. Probier mal, ob es noch etwas schneller ist, wenn du den expliziten

Delphi-Quellcode:

Sort

-Aufruf weglässt.

Gute Information.
Ich hatte extra noch den STRG+Linksklick auf .Sorted gemacht um danach zu suchen. Bin aber erst daran gescheitert es zu finden.
Bis

Delphi-Quellcode:

procedure TStringList.SetSorted(Value: Boolean);

bin ich gekommen und habe dort dann diese wunderschöne Zeile

Delphi-Quellcode:

if Value then Sort;

übersehen.

Ich werde das später mal mit der TStopWatch prüfen.

[EmWieMichael]

Zitat:

Zitat von himitsu (Beitrag 1358378)

Rein "logisch" nur eine mathematische Rechnung.

Delphi-Quellcode:

V = A - B

(gleich 0, kleiner 0, größer 0)
CompareValue
Dann weiß man sofort ob größer, kleiner oder gleich.
...

Wahrscheinlich steh´ ich wirklich auf´m Schlauch :shock:: Ich habe jetzt eine Rechnung aufgestellt und das Ergebnis steht in 'V'; ich weiß, dass 'V' kleiner 0, größer 0 oder gleich 0 ist. Um auf dieses Ergebnis zu reagieren, benötige ich doch immer noch zwei Vergleiche:

Code:

...
if (V = 0) then 
 begin
   Gefunden; 
   Break;
 end; 
if (V < 0) then 
 SuchindexNachUnten;
else
 SuchindexNachOben;
...

[Klaus01]

oder so:

Delphi-Quellcode:

case v of
  low(Integer) .. -1: SuchIndexNachUnten;
  0: Gefunden;
  1 .. high(Integer): SuchIndexNachOben;
end;

Grüße
Klaus

[EmWieMichael]

Zitat:

Zitat von Klaus01 (Beitrag 1358440)

oder so:

Delphi-Quellcode:

case v of
  low(Integer) .. -1: SuchIndexNachUnten;
  0: Gefunden;
  1 .. high(Integer): SuchIndexNachOben;
end;

Richtig, geht auch; allerdings dürfte diese Variante (wenigstens theoretisch) langsamer sein.

[p80286]

@a.def
wenn du mit

Delphi-Quellcode:

.sorted:=True;

arbeitest, dann mußt Du noch eine Behandlung von doppelten Datensätzen mit einbauen z.B.

Delphi-Quellcode:

.Duplicates:=dupIgnore;

Gruß
K-H