Inoffizielles deutsches Xbase-Forum

Dann sollten wir das auf der DevCon machen. Der Chat im April fällt aus, weil wir da ja gerade erst aus Isernhagen zurück sind. Das wird dann etwas viel für den Monat.

Jan

Hi Tom,

Deine Ausführungen sind durchaus verständlich. Ich glaube aber nicht, dass Alaska da was ändern wird. Dazu müsste ja wirklich in bestimmten Situationen (nämlich wenn ein Datensatz aus dem Unique-Index fliegt) eine komplette Sichtung der Daten in der DBF erfolgen, um festzustellen, ob es einen weiteren Kandidaten gibt, der nun "nachrücken" könnte. Das ist Laufzeittechnisch sicher mehr als problematisch. Oder es müssten gleich alle Datensätze im Unique-Index enthalten sein und nur durch die "Navigation" das unique generiert werden (ähnlich wie beim Scope).

PS: Ich habe es einfach. Ich verwende Unique-Indexe nur temporär (durchaus für von Dir genannte Beispiele).

Hallo, Markus.

Das Problem sehe ich ebenfalls, wie ich ja auch mehrfach erwähnt habe. Georg hat es veranschaulicht: Der Unique-Index "sieht" eben nur einen Teil der Datensätze. Bei Änderungen oder Ergänzungen ist das unproblematisch, aber bei Löschungen müsste eben die komplette Datenquelle gesichtet werden, was bei einigen tausend Datensätzen ziemlich haarsträubend werden könnte. Implizite Mechanismen (der Index enthält doch alle Datensätze, aber die Engine überspringt sie) wären keine Lösung, denn dann wäre ja nicht mehr der Index selbst "unique".

Ich kann aber mit diesem - nunmehr bekannten - Fehlverhalten umgehen. Dank an Jan dafür, dass er das Problem entdeckt hat! =D>

Am Besten wäre eine Erweiterung durch ein Flag, mit dem ein normaler Index die doppelten Sätze automatisch überspringt.
So könnte man sich einen Index sparen, alle Probleme wären beseitigt und dennoch würden die alten Programme genauso weiterlaufen wie sie sind

Hm,

wäre es bei einem Flag nicht so, dass die doppelten übersprungen werden müßten? Das käme doch einem Filter gleich, oder? Das frisst doch Zeit? In einem Unique ist ja immer nur max. 1 Satz vorhanden, da muß nicht gesprungen werden.

Hallo Manfred,

ein Filter ist nicht automatisch langsam !
Langsam ist er nur, wenn er sehr viele Datensätze ohne Treffer überspringen muss.
Ich nutze gerne einen Hauptindex der die Daten begrenzt (auch mit scope) und dann darin einen Filter für komplexere Aufgaben.

Wie wäre es bei dem geschilderten Problem ?
Wahrscheinlich ist es eher selten, dass viele Datensätze den gleichen Indexkey haben, diese liegen auch sortiert hintereinander UND
die DBE könnte nach dem ersten Treffer einen dbseek() auf den Datensatz mit einem höheren Indexbegriff vornehmen.
Die Performance wäre in den allermeisten Fällen genauso schnell wie bisher, wenn man die Verwaltung eines extra Index sparen kann,
könnte es sogar schneller werden.

Ich stehe jetzt aiuch vor dem Problem. Wäre es dann wirklich eine bessere Lösung das mit einem CANDIDATE Index zu lösen?