Index On mit FOR [Erledigt]

[Jan]

Ich habe noch nie die FOR-Klausel in der Index-Erstellung benutzt. Und bevor da irgendwas schief läuft frage ich mal vorher in die Runde:

Ich würde gerne einen Index erstellen, in dem schon von vorneherein Datensätze garnicht auftauchen. Wenn ich nun in FOR angebe: Nimm bitte nicht die Datensätze mit in den Index auf, in denen in einem Datenbankfeld ein bestimmter Wert steht. Dann sollte das wohl funktionieren, denke ich. Was passiert aber, wenn sich die Bedingungen in einem Datensatz ändern? Wird der betreffende Satz dann z. B. automatisch aus dem Index rausgeworfen bzw. aufgenommen?

Ich frage extra, weil ich ja beim UNIQUE schon in die ganz böse Falle gelaufen war...

Jan

[Tom]

Hallo, Jan.

Gebräuchlichstes Beispiel hierfür ist: INDEX ON ... FOR !Deleted(). Gelöschte Datensätze tauchen dann im Index nicht auf, was den Vorteil hat, dass die DBE diese - bei SET DELETED ON - nicht überspringen muss, um den gesuchten Eintrag zu finden. Man kann sie allerdings dann über diesen Index überhaupt nicht mehr finden. Aber: DbGoto(n) springt immer zu Datensatz "n", selbst wenn dieser gelöscht ist oder in einem aktuellen Filter, Scope usw. ungültig wäre. Ist allerdings DELETED auf ON, sieht man ihn trotzdem nicht (sondern den Phantomdatensatz). Konditionale Indexe werden von der DBE automatisch gepflegt. Löse ich also ein RECALL aus, sind die gelöschten Datensätze wieder im konditionalen Index. "Entlösche" ich sie aber von außen, ohne dass ich den Index aktiv habe, sind sie (noch) nicht wieder vorhanden, sondern erst nach einem Reindex. Man muss bei solchen Ausdrücken etwas aufpassen, wenn man die ADS verwendet, denn die kennt nicht alle Xbase-Funktionen.

Ergänzung: Man kann das auch mischen, also beispielsweise zwei Indexe auf dem selben Feld haben, einer mit "FOR !Deleted()" und einer ohne das. Beide werden automatisch gepflegt; der eine findet keine gelöschten Datensätze (ganz unabhängig von SET DELETED!), der andere durchaus, wenn SET DELETED OFF ist.

[brandelh]

Einfache Antwort ... die FOR Bedingung wird im Index gespeichert, der WHILE nicht !

Also wenn du ein FOR setzt und neue Datensätze angefügt werden, müssen diese auch die FOR Bedingung erfüllen um im Index zu landen.
So wie du es willst

[Manfred]

ich habe die Frage so verstanden, dass es darum ging wenn sich ein bestehender Satz ändert, nicht wenn ein neuer hinzukommt.

[brandelh]

ich habe die Frage so verstanden, dass es darum ging wenn sich ein bestehender Satz ändert, nicht wenn ein neuer hinzukommt.

Von der Anforderung ist das das Gleiche
Aber OK, JA es funktioniert auch beim Speichern eines geänderten Datensatzes
Nach einer Änderung kann er also genauso "rausfliegen" wie nach einer Löschung, damit muss das Programm klar kommen.

PS: wenn man mit dbGoTo() auf einen Satz springt, der nicht im Index ist und den Indexbegriff so ändert,
dass er nun rein passt, wird er nach dem Speichern und Refresh auch sichtbar sein.

[Tom]

Der Unterschied zu UNIQUE besteht darin, dass nur für den aktuellen/aktuell veränderten Datensatz geprüft werden muss, ob er der Bedingung genügt und bereits im Index enthalten ist. Funktioniert nach meiner Beobachtung problemlos, auch mit inhaltlichen Bedingungen wie "FOR !Left(name,1)=='_'".

[Jan]

Moin Hubert, Tom, und Manfred,

vielen Dank für Eure Antworten. Die Bestätigungen helfen mir sehr weiter.

Jan