Candidate Index
Moderator: Moderatoren
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Candidate Index
Hallo,
ein Candidate Index, wird der genauso automatisch aktualisiert usw. wie der normale Index?
Ich habe folgendes Szenario:
1) DBF die auf ein Feld "Nummer" indiziert ist.
2) Diese DBF soll dann über einen SCope nur eine Nummer anzeigen.
3) Das Ergebnis hat dann zwar nur etliche Sätze der einen Nummer, aber mehrere Spalten, in denen dann wieder doppelte andere Nummern auftauchen können.
4) diese doppelten anderen Nummern sollen aber zu nur einem Satz erscheinen, also ein Unique.
Löst man sowas über Candiate oder SubIndex, oder wie? Ich wüßte jetzt nicht, wie ich ein Unique im Index auf ein weiteres Feld als die Hauptnummer legen sollte.
ein Candidate Index, wird der genauso automatisch aktualisiert usw. wie der normale Index?
Ich habe folgendes Szenario:
1) DBF die auf ein Feld "Nummer" indiziert ist.
2) Diese DBF soll dann über einen SCope nur eine Nummer anzeigen.
3) Das Ergebnis hat dann zwar nur etliche Sätze der einen Nummer, aber mehrere Spalten, in denen dann wieder doppelte andere Nummern auftauchen können.
4) diese doppelten anderen Nummern sollen aber zu nur einem Satz erscheinen, also ein Unique.
Löst man sowas über Candiate oder SubIndex, oder wie? Ich wüßte jetzt nicht, wie ich ein Unique im Index auf ein weiteres Feld als die Hauptnummer legen sollte.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2823
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 95 Mal
- Danksagung erhalten: 13 Mal
Re: Candidate Index
Hallo, Manfred -
Du kannst mehrere Index-Dateien mit dem Attribut UNIQUE anlegen. Wo siehst Du das Problem?
Du kannst mehrere Index-Dateien mit dem Attribut UNIQUE anlegen. Wo siehst Du das Problem?
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Jan
- Marvin
- Beiträge: 14641
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 87 Mal
- Kontaktdaten:
Re: Candidate Index
Manfred,
pass mit Unique-Indizee auf. Da bin ich schon ganz böse mit reingefallen, weil die nicht korrekt aktualisiert wurden.
Jan
pass mit Unique-Indizee auf. Da bin ich schon ganz böse mit reingefallen, weil die nicht korrekt aktualisiert wurden.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Candidate Index
Hallo Georg,
ich benötige ein "unique" auf ein weiteres Feld und nicht auf den Haupteintrag. Da wüßte ich jetzt nicht, wie ich das lösen sollte.
ich benötige ein "unique" auf ein weiteres Feld und nicht auf den Haupteintrag. Da wüßte ich jetzt nicht, wie ich das lösen sollte.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Candidate Index
Man kann Scopes auch mit Filtern kombinieren, in denen UDFs verwendet werden, beispielsweise solche, die sich bereits existierende Referenzen merken. Filter auf gescopten Tabellen sind ziemlich fix, wenn die Datenmenge überschaubar ist, und ergänzt um Smartfilter (Vorsicht: bei Datenänderung DbRefresh() aufrufen!) in Browses sogar wieselflink, weil die Filterbedingung je Datensatz nur einmal evaluiert wird.
Das Problem bei UNIQUE-Indexen besteht darin, dass der zuerst indexierte Datensatz im Index berücksichtigt wird. Löscht man diesen Datensatz, rückt ein etwaiger anderer, der die gleiche Referenz enthält, nicht automatisch nach:
Rec 1, ID = "5500" // dieser Datensatz ist im UNIQUE-Index auf "ID"
Rec 2, ID = "6600" // dieser auch
Rec 3, ID = "5500" // der nicht
Lösche ich jetzt Rec 1, wird "5500" über den UNIQUE-Index nicht mehr gefunden. Das geschieht erst, wenn ich auf Datensatz 3 gehe und ID mit ihrem bestehenden Wert ersetze. Das liegt daran, dass die Engine bei der Indexaktualisierung ansonsten die gesamte Tabelle durchsuchen müsste, ohne einen etwaigen weiteren Index verwenden zu können. Deshalb muss man sich in solchen Konstellationen Servicefunktionen bauen, die dieses Szenario reflektieren.
Das Problem bei UNIQUE-Indexen besteht darin, dass der zuerst indexierte Datensatz im Index berücksichtigt wird. Löscht man diesen Datensatz, rückt ein etwaiger anderer, der die gleiche Referenz enthält, nicht automatisch nach:
Rec 1, ID = "5500" // dieser Datensatz ist im UNIQUE-Index auf "ID"
Rec 2, ID = "6600" // dieser auch
Rec 3, ID = "5500" // der nicht
Lösche ich jetzt Rec 1, wird "5500" über den UNIQUE-Index nicht mehr gefunden. Das geschieht erst, wenn ich auf Datensatz 3 gehe und ID mit ihrem bestehenden Wert ersetze. Das liegt daran, dass die Engine bei der Indexaktualisierung ansonsten die gesamte Tabelle durchsuchen müsste, ohne einen etwaigen weiteren Index verwenden zu können. Deshalb muss man sich in solchen Konstellationen Servicefunktionen bauen, die dieses Szenario reflektieren.
Herzlich,
Tom
Tom
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2823
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 95 Mal
- Danksagung erhalten: 13 Mal
Re: Candidate Index
Hallo, Manfred -
erstelle einen "Report-Index", also etwa
INDEX ON meinFeld TO RepIndex UNIQUE
und verwende dann diesen Index für die Anzeige.
Damit kommen wir dann aber wieder zu dem alten Thema "Warum wird mein UNIQUE-Index nicht richtig aktualisiert", den Jan ansprach. In Abhängigkeit von der Anforderung würde ich diesen Index nur temporär erstellen, wenn er benötigt wird, und danach wieder löschen, um sicher zu sein, dass entsprechende Änderungen auch in den im Index gelisteten Sätze abgebildet werden.
Wenn Du das nicht temporär machen kannst/willst, musst Du sicherstellen, dass der Index immer offen ist, wenn Änderungen an der Datei vorgenommen werden, aber (siehe Jan) Du kannst nicht sicher sein, dass alle Änderungen auch abgebildet werden.
Hatte ich schon mal erwähnt, dass das mit SQL deutlicher einfacher ist? Ach, ja? Na gut, dann verzichte ich diesmal auf den Hinweis.
erstelle einen "Report-Index", also etwa
INDEX ON meinFeld TO RepIndex UNIQUE
und verwende dann diesen Index für die Anzeige.
Damit kommen wir dann aber wieder zu dem alten Thema "Warum wird mein UNIQUE-Index nicht richtig aktualisiert", den Jan ansprach. In Abhängigkeit von der Anforderung würde ich diesen Index nur temporär erstellen, wenn er benötigt wird, und danach wieder löschen, um sicher zu sein, dass entsprechende Änderungen auch in den im Index gelisteten Sätze abgebildet werden.
Wenn Du das nicht temporär machen kannst/willst, musst Du sicherstellen, dass der Index immer offen ist, wenn Änderungen an der Datei vorgenommen werden, aber (siehe Jan) Du kannst nicht sicher sein, dass alle Änderungen auch abgebildet werden.
Hatte ich schon mal erwähnt, dass das mit SQL deutlicher einfacher ist? Ach, ja? Na gut, dann verzichte ich diesmal auf den Hinweis.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9345
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 100 Mal
- Danksagung erhalten: 359 Mal
- Kontaktdaten:
Re: Candidate Index
Hallo, Georg.
Siehe letztes Posting von mir. Man benötigt einen zweiten Index (ohne UNIQUE), der dasselbe Feld berücksichtigt, und muss nach jeder Aktualisierung des Feldes (Änderung, Löschung) prüfen, ob es noch in beiden Indexen gefunden wird. Ist das nicht der Fall, muss man nach dem zweiten Index suchen und das Feld mit seinem eigenen Wert ersetzen, dann ist der UNIQUE-Index wieder aktuell. Jedenfalls, wenn man den Index nicht nur temporär benötigt.In Abhängigkeit von der Anforderung würde ich diesen Index nur temporär erstellen, wenn er benötigt wird, und danach wieder löschen, um sicher zu sein, dass entsprechende Änderungen auch in den im Index gelisteten Sätze abgebildet werden.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Candidate Index
@Tom,
ich glaube Du hast den Nagel auf den Kopf getroffen. Die Filter kann man ja als logische Rückgabe betrachten. Ich muß mir nur merken, ob eine Nummer schon mal dran war (indem ich eine Funktion als Filter setze) und dann ein .F. für weitere zurückliefern. So habe ich das noch nicht betrachtet. Manchmal kann es so einfach sein.
ich glaube Du hast den Nagel auf den Kopf getroffen. Die Filter kann man ja als logische Rückgabe betrachten. Ich muß mir nur merken, ob eine Nummer schon mal dran war (indem ich eine Funktion als Filter setze) und dann ein .F. für weitere zurückliefern. So habe ich das noch nicht betrachtet. Manchmal kann es so einfach sein.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Candidate Index
Hm,
zu früh gefreut.
Es wird im Browse nur 1 Satz angezeigt.
zu früh gefreut.
Code: Alles auswählen
(oStunden:nArea)->(DbSetScope(SCOPE_BOTH,(oTagesdienst:nArea)->dienstbez))
(oStunden:nArea)->(DbSetFilter({|| ::fahrerfiltern(oStunden)}))
********************************************************************************
METHOD DialogTagesdienste:fahrerfiltern(oStunden)
LOCAL lErfolg := .F.
IF AScan(::aFahrerfilter,(oStunden:nArea)->idfahrer) = 0
AAdd(::aFahrerfilter,(oStunden:nArea)->idfahrer)
lErfolg := .T.
ENDIF
RETURN lErfolg
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2932
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Candidate Index
Schaufel dir benötigten Daten in ein Array und zeige das an.
Viele Grüße
Wolfgang
Wolfgang
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Candidate Index
hatte ich auch erst dran gedacht, aber dann erschien mir der Vorschlag von Tom ganz sympathisch. Ich denke aber, wenn das mit dem Filter nix wird, dann mache ich es so.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Re: Candidate Index
Hallo Manfred
wenn es wie Du schreibst immer nur wenige Datensätze bereits beim ersten Scope sind würde ich diese Datensätze in eine lokale Hilfs-DB(#1) kopieren und das Weitere entweder über einen Unique Index lösen oder mit Scope + Index das nächste Ergebnis in eine Hilfs-DB(#2) kopieren bis Du das End-Ergebnis hast. Hört sich "Umständlich" an macht die heutige Technik affenschnell
Um das bei sehr langen Records noch zu beschleunigen kannst Du ja nur die benötigten Felder in die Hilfs-DB kopieren. Ich füge dann noch ein Record-Nummern-Feld ein welches die Original-Record-Nr. beinhaltet. Diese RecNo verwende Ich nach dem Filtern um den/die tatsächlichen Records aus der Original-DB anzuzeigen.
So etwas verwende ich schon länger und häufiger für Suchen und Auswertungen.
Wie gesagt: wichtig ist, dass die erste Filter-Funktion bereits eine einigermaßen Überschaubare Anzahl von Records bringt. Sonst macht ab einer bestimmten Größe dieser Weg keinen Sinn mehr (wegen dem Kopieren).
Gruß
Roland
wenn es wie Du schreibst immer nur wenige Datensätze bereits beim ersten Scope sind würde ich diese Datensätze in eine lokale Hilfs-DB(#1) kopieren und das Weitere entweder über einen Unique Index lösen oder mit Scope + Index das nächste Ergebnis in eine Hilfs-DB(#2) kopieren bis Du das End-Ergebnis hast. Hört sich "Umständlich" an macht die heutige Technik affenschnell
Um das bei sehr langen Records noch zu beschleunigen kannst Du ja nur die benötigten Felder in die Hilfs-DB kopieren. Ich füge dann noch ein Record-Nummern-Feld ein welches die Original-Record-Nr. beinhaltet. Diese RecNo verwende Ich nach dem Filtern um den/die tatsächlichen Records aus der Original-DB anzuzeigen.
So etwas verwende ich schon länger und häufiger für Suchen und Auswertungen.
Wie gesagt: wichtig ist, dass die erste Filter-Funktion bereits eine einigermaßen Überschaubare Anzahl von Records bringt. Sonst macht ab einer bestimmten Größe dieser Weg keinen Sinn mehr (wegen dem Kopieren).
Gruß
Roland
- Manfred
- Foren-Administrator
- Beiträge: 21165
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 206 Mal
- Danksagung erhalten: 67 Mal
Re: Candidate Index
Ich erzeuge jetzt schon eine Tempdatei und lese dann daraus das Ergebnis. Aber trotzdem interessiert mich, warum mein oben genanntes Beispiel nicht klappt.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!