Index Treiber

[Manfred]

Genau,

und Korruption ist anderen Leuten gegeben

[Armin]

huhu,

nochmals zu NTX

Ich merke mir in einer Logdatei, wenn jemand ein Programm aufruft, in dem ich einen Satz schreibe und diesen sperre. Beim Verlassen lösche ich diesen Satz wieder. Ist beim nächsten Mal ein Satz ohne Sperre vorhanden, so weiss ich, dass das Programm abgebrochen wurde (Absturz, Abschuss mit ALT-C, Win-Taskmanager oder einfach Rechner abschalten). In diesem Falle lasse ich alle Indexdateien neu aufbauen - das hat die Anwender wohl auch erzogen, die Programme ordentlich zu verlassen

Ausserdem achte ich noch darauf, dass die Indexdateien relativ eindeutige Sätze haben. Also jetzt nicht eine Adress-dbf auf ORT indizieren und dann gibt´s z.B. hunderte Berliner und nur ein Engelsbrander. Dann erweitere ich den Schlüssel eben, bis er eindeutiger wird.

herzlichst Armin

[Manfred]

Hallo Armin,

Ausserdem achte ich noch darauf, dass die Indexdateien relativ eindeutige Sätze haben. Also jetzt nicht eine Adress-dbf auf ORT indizieren und dann gibt´s z.B. hunderte Berliner und nur ein Engelsbrander. Dann erweitere ich den Schlüssel eben, bis er eindeutiger wird.

Irgendwie meine ich in gelesen zu haben, das Xbase++ automatisch die RECNO() mitspeichert um auf jeden Fall eindeutig zu sein.

[Tom]

Jeder Eintrag einer Indexdatei verweist auf einen Datensatz in der DBF, und nur auf einen. Auch wenn es tausend Berliner und nur einen Engelsbrander (was'n das? ) gibt, verweist jeder Eintrag für "Berlin" auf genau den dazugehörigen Eintrag in der DBF. Indexe dienen ja vorrangig der schnellen Suche, und auf diese Art findet man eben alle Berliner, weil sie konsequenterweise aufeinanderfolgen, so daß man mit einer einfachen DO .. WHILE-Schleife (oder besser: einer Relation oder einem Scope) alle Berliner ausfiltern kann.

Wenn man ein-eindeutige Indexe braucht, muß man einen Schlüssel vergeben, zum Beispiel eine Nummer. Zudem hilft die Option "UNIQUE", ein-eindeutige Indexe aufzubauen, aber das macht natürlich nur dann Sinn, wenn diese reduzierende Eindeutigkeit erforderlich ist, weil ein entsprechender Index nicht mehr auf alle Einträge verweisen würde. Beispiel wäre ein Straßenverzeichnis, das gleichzeitig als Postleitzahlen-/Ortsverzeichnis genutzt wird. Ein UNIQUE-Index auf "ORT" würde nur eine Liste aller VERSCHIEDENEN Orte liefern, aber für die Straßen schaltet man auf einen Index um, der nicht mehr UNIQUE ist. Zudem gibt es gleiche Orte mit verschiedenen Postleitzahlen - und umgekehrt Postleitzahlen, die auf verschiedene Orte verweisen.

[Manfred]

Hi Tom,

entweder verstehe ich Dich jetzt nicht, oder.....

Wenn man z.B. einen Index auf ein numerisches Feld macht, von dem es in einer DB mehrere gleiche gibt, wurde mir damals vom CA Support gesagt, man soll die RECNO() mit speichern. Empfohlen wurde damals L2BIN(RECNO()), damit es nicht zu einem Crash kommt.

[Tom]

Hallo, Manfred.

Das ist Unsinn - vielleicht hast Du da auch was falsch verstanden. Du kannst ja beliebig viele Indexe zu einer DBF aufbauen, und ob überhaupt einer davon eindeutig ist, hängt davon ab, ob Du das brauchst. Wenn Du über einen Index suchst (z.B. mit DbSeek() oder SEEK), findest Du immer den ersten Eintrag (in der DBF), der diesem Ausdruck entspricht (oder EoF() feuert). Mit DbSkip() (oder SKIP) kommst Du zum nächsten, und wenn es mehrere Einträge gibt, die diesem Index entsprechen, fragst Du einfach ab, ob die Kondition zutrifft. Einfacher ist es mit dem Scoping-System. Wenn Du wissen willst, wieviele Kunden genau einen Hund haben, setzt Du ein Scope auf den Index, der z.B. auf Str(Hundezahl,10,0) gesetzt ist:

Code: Alles auswählen

DbSetScope(SCOPE_BOTH,Str(nMeineHundeZahl,10,0))

DbGoTop() springt dann automatisch auf den ersten Eintrag (es geht auch mit numerischen Werten, aber Alaska empfiehlt, immer Indexe zu bilden, die aus Zeichenketten bestehen), und Du siehst von dieser DBF nur diejenigen Einträge, wo die Hundezahl "1" ist (bzw. nMeineHundeZahl entspricht). Sowas geht nur mit einem Index, jedenfalls sehr schnell - Filter sind viel langsamer. Indexe dienen auch der Sortierung - es kann beliebig viele Müllers in einer Adreßdatei geben, aber um diese Adreßdatei in Reihenfolge der Namen anzuzeigen, setze ich eben einen Index (permanent) auf die Namen. Undsoweiter.

[Tom]

Nochwas:

Empfohlen wurde damals L2BIN(RECNO()), damit es nicht zu einem Crash kommt.

Es kann gefährlich sein, mit der Recordnumber zu arbeiten, weil sie nach einem DbPack() neu vergeben wird.

[Martin Altmann]

Hallo Manfred,
wenn man eine Eineindeutigkeit will, muss man das so machen! Wenn man die Daten nur in einer bestimmten Reihenfolge haben möchte (für eine Listeausgabe) nicht!
Wichtig!! Nie eine Indexdatei über mehrere numerische Felder aufbauen - in dem Fall immer über Zeichenketten!! Die numerischen Felder würden sonst addiert werden, was ja nicht Sinn der Sache ist!!

Viele Grüße,
Martin

Diesmal war der Tom schneller Die armen Hunde, wofür die alles herhalten müssen...

[Tom]

Mag sein, aber es macht überhaupt keinen Sinn, einen Index über die Recordnumber aufzubauen, denn dieser Index steht immanent zur Verfügung und kann per DbGoto(nRecno) benutzt werden. Oder verstehe ich jetzt was falsch?

[Martin Altmann]

Hallo Tom,

Oder verstehe ich jetzt was falsch?

Jup! Es geht nicht darum, eine Datei nach der Recordnummer zu indizieren! Ohne Index ist das ja automatisch der Fall!
Es geht darum, eine Eineindeutigkeit zu bekommen - also einerseits eine sortierte Reihenfolge aber andererseits soll kein Indexausdruck doppelt vorkommen.
Wann immer man sowas braucht, bietet sich dafür dann die Recno() an - die ist garantiert nur einmalig vorhanden!
Das dieses Vorgehen bei einem dauerhaften Index seine Probleme mit sich bringen kann, hast Du ja schon dargelegt (DbPack()).

Viele Grüße,
Martin

[Tom]

Es geht darum, eine Eineindeutigkeit zu bekommen - also einerseits eine sortierte Reihenfolge aber andererseits soll kein Indexausdruck doppelt vorkommen.

Das scheint mir ein etwas abstruser und recht unsicherer Weg zu sein, derlei zu erreichen.

[Martin Altmann]

Hallo Tom,
aber der Einfachste
Ich schau mal nachher in den Newsgroups von Alaska - da war vor einigen Monaten einer, der hatte genau das Problem. Ich hatte ihm auch dazu geraten und er war damit sehr zufrieden.
Ich weiß leider nicht mehr, wozu er diesen Index brauchte, aber ich schau heute Abend/Nacht mal nach und poste das dann hier.

Viele Grüße,
Martin

[Manfred]

stop stop stop,

jetzt wird die Schlagzahl aber recht hoch

Ich komme gar nicht mehr zum Antworten.

Also, das mit der RECNO() und dem PACK wäre natürlich nachvollziehbar, aber ist das nicht Wurscht? Bei L2BIN(RECNO()) wird doch nur ein Wert hinzugezogen, um eben diese Eindeutigkeit zu erlangen.

Klärt mich auf, wenn ich hier etwas durcheinander bringe.

Wichtig!! Nie eine Indexdatei über mehrere numerische Felder aufbauen - in dem Fall immer über Zeichenketten!! Die numerischen Felder würden sonst addiert werden, was ja nicht Sinn der Sache ist!!

Martin, nur zur Beruhigung, das war das erste was ich bitter lernen mußte, dass man einen String bilden muß

[Martin Altmann]

Hallo Manfred,

Martin, nur zur Beruhigung, das war das erste was ich bitter lernen mußte, dass man einen String bilden muß

dann bin ich ja beruhigt, dass es nicht nur mir so ging

Viele Grüße,
Martin

[Tom]

Bleibt noch die Frage, wozu das gut sein soll. Kann ich mir, um ehrlich zu sein, im Moment keine Antwort zu vorstellen.

[Manfred]

Bleibt noch die Frage, wozu das gut sein soll. Kann ich mir, um ehrlich zu sein, im Moment keine Antwort zu vorstellen.

Ich meine mich erinnern zu können, das es mir damals so erklärt wurde, dass es unbedingt sein muß, wenn ein Schlüssel mehrfach vorkommt. Ich hatte nämlich damals schon ein Problem mit defekten Indexdateien und deshalb nachgefragt. RECNO() alleine sollte man nicht machen.

Leider habe ich in meinen alten Unterlagen nur stehen, dass ich es eingebaut habe, aber nicht mehr die genaue Erklärung. Für mich war es damals nachvollziehbar und deshalb......

[thomas]

Hallo Manfred.

Kein Angst, Tom und Martin lauer ständig hier im Forum und überbieten sich mit schnellen Eingebungen.
Zum Thema Recno() im Indexschlüssel:
Es macht gar keinen Sinn die Recordnummer im Schlüssel zu verewigen, denn wie gesagt verursacht
ein PACK() das die Eineindeutigkeit verloren geht.

Gruß

Thomas

[Manfred]

Hi Thomas

au weiah, jetzt klingelt es.......

stimmt, mit jeder Änderung wird ja der Index angepackt und dort steht ja drin, das die RECNO() benutzt wird. Deshalb ändert die sich auch immer, bei jeden PACK z.B.

Was sollte denn dann der Unsinn damals? Alles recht merkwürdig

Deshalb bekomme/bekam ich auch bei meiner Funktion mit der Recno() Anzeige immer eine Nummer mitten ins Bild geschrieben...

[Tom]

Hallo, Manfred.

Ich verstehe es nicht - wozu soll dieser Schlüssel gut sein?

Eine DBF liegt immer in Reihenfolge der Datensatznummer vor, und die ergibt sich aus der Reihenfolge der Erfassung. Die Datensatznummer wird neu vergeben, wenn man packt oder sortiert. Mit DbGoto() komme ich zu dem Datensatz, der eine bestimmte Datensatznummer hat. Was aber unterscheidet in der Anwendung einen Index der Form:

Code: Alles auswählen

INDEX ON Upper(Name) To MyIndex

von

Code: Alles auswählen

INDEX ON Str(Recno(),10,0)+Upper(Name) To MyIndex

außer, das man mit dem zweiten nicht mehr suchen kann?

[Martin Altmann]

Hallo Thomas,
genau - darum macht das in dauerhaften Indexen keinen Sinn - spricht aber nichts dagegen, es in temporären zu verwenden.
Zum Thema Pack: So was macht man sowieso nicht Phil Ide hat dazu in den Newsgroups recht interessante Tipps gegeben. Aus Gründen der Revisionssicherheit sind mit seiner Vorgehensweise immer zu jeder Zeit jeder Stand der Daten abrufbar.

• Ein Datensatz wird nie gelöscht - es wird immer in einem speziellen Feld ein Marker gesetzt, der dem Löschen entspricht - ist dieser Marker gesetzt, wird der Datensatz in Listen usw. nicht mehr berücksichtigt.
• Eine Änderung an einem Datensatz wird nie in dem originalen Datensatz durchgeführt - der Datensatz wird vorher immer in einen neuen Datensatz kopiert und dort werden die Änderungen hinterlegt.
• Ein Entlöschen passiert auch durch Kopieren des "gelöschten" Datensatz und entfernen des Löschmarkers in der Kopie.
• Zu all' diesen Aktionen wird auch der Zeitpunkt der Änderung/Löschung und der Account des betreffenden Users, die die Änderung/Löschung vorgenommen hat, abgelegt.

So ist jederzeit immer alles rekonstruierbar!
In einem solchen Fall hat man auch keine Probleme mit der Recno()

Tom, Gedulde Dich noch ein wenig, ich kann die Newsgroups ja leider nur von zu Hause lesen...

Viele Grüße,
Martin

[Martin Altmann]

Hallo Tom,

Code: Alles auswählen

INDEX ON Str(Recno(),10,0)+Upper(Name) To MyIndex

Dreh' das mal um:

Code: Alles auswählen

INDEX ON Upper(Name)+Str(Recno(),10,0) To MyIndex

macht latürnich mehr Sinn, da es jetzt auch nach Namen sortiert ist (ältester Eintrag zuerst).
Und latürnich kann man dann auch nach einem Namen suchen

Viele Grüße,
Martin

[Tom]

Und wozu? Das ist doch sozusagen in-of-itself. Wenn ich einen Index auf den Namen setze, bekomme ich die Datensätze in der Reihenfolge der Namen und in sich nochmals sortiert nach der Datensatznummer (weil sie in dieser Reihenfolge sowohl in der DBF, als auch im Index vorliegen).

[thomas]

Hallo Manfred. Hallo Tom. Hallo Martin.

Ich denke es macht sehr viel Sinn jeder DBF-Dateie einen eineindeutigen (Unique) Schlüssel zu verpassen.
Ein Blick in die Zukunft könnte bedeuten, das wir z.B. unsere DBF-Dateien auf verschiedenen Server synchronisieren wollen und zwar in Echt-Zeit. Mit ADS Vers. 8 kommt man der Sache schon sehr nahe.
Ich habe in jeder DBF Datei ein Time-Stamp als eineindeutigen Schlüssel gespeichert. Das klapp auch ganz gut,
solange man nicht mehr als 1000 Sätze pro Sekunde speichern will.
Den Befehl PACK() habe ich sowieso aus meinem Sprachumfang gestrichen.

Gruß

Thomas

[Manfred]

Hi Martin

Zum Thema Pack: So was macht man sowieso nicht Phil Ide hat dazu in den Newsgroups recht interessante Tipps gegeben. Aus Gründen der Revisionssicherheit sind mit seiner Vorgehensweise immer zu jeder Zeit jeder Stand der Daten abrufbar.

• Ein Datensatz wird nie gelöscht - es wird immer in einem speziellen Feld ein Marker gesetzt, der dem Löschen entspricht - ist dieser Marker gesetzt, wird der Datensatz in Listen usw. nicht mehr berücksichtigt.
• Eine Änderung an einem Datensatz wird nie in dem originalen Datensatz durchgeführt - der Datensatz wird vorher immer in einen neuen Datensatz kopiert und dort werden die Änderungen hinterlegt.
• Ein Entlöschen passiert auch durch Kopieren des "gelöschten" Datensatz und entfernen des Löschmarkers in der Kopie.
• Zu all' diesen Aktionen wird auch der Zeitpunkt der Änderung/Löschung und der Account des betreffenden Users, die die Änderung/Löschung vorgenommen hat, abgelegt.

So ist jederzeit immer alles rekonstruierbar!

ich verstehe kein Wort.....

[Tom]

Hallo, Manfred.

ich verstehe kein Wort.....

Es geht darum, die strukturelle Integrität der Daten zu erhalten. In einer DBF hat jeder Datensatz nur so lange seine eindeutige Datensatznummer (Recno()), bis die DBF gepackt, sortiert oder umkopiert wird (wenn bei letzterem ein führender Index aktiv ist). Bei Phils Vorschlägen geht es darum, sowohl inhaltlich, als auch referentiell immer nachvollziehen zu können, was mit den Daten geschehen ist, und deshalb kopiert er geänderte Datensätze (der Urdatensatz bleibt erhalten, wird aber ausgeblendet, was man mit SET DELETED ON und einem einfachen Löschen auch erreichen kann). Er packt nie, er kopiert nie um, und er speichert Änderungsinformationen direkt im Datensatz. Das kann unter entsprechenden Bedingungen alles Sinn machen, und es erspart viel Unbill, die mit Reihenfolgen und Referenzen über die Datensatznummer zu tun hat. Aber es ist nicht so, daß man auf diese Art arbeiten muß.