Index Treiber

[Martin Altmann]

Hallo Manfred,
Phils Vorgehensweise sorgt im Prinzip dafür, dass ein einmal eingegebener Datensatz nie mehr verändert wird und somit immer wieder rekonstruierbar ist. Soll ein alter Datensatz geändert werden, so wird vom Programm her ein neuer Datensatz mit den alten Daten angelegt und der User kann die Änderungen vornehmen.
Trotz allem ist der ursprüngliche Datensatz noch immer unverändert erhalten. Er wird jedoch als "alt" markiert, so dass bei den normalen Listen oder dem normalen Suchen dieser Satz nicht mehr berücksichtigt wird.
Es kann aber jederzeit eine Änderunghistorie erzeugt werden (wer hat was bei dem Kunden Müller wann geändert). Somit lässt sich eine Änderung jederzeit auch wieder zurücknehmen - natürlich auch in diesem Fall durch das obige Vorgehen.
Dies ist ein z.B. bei Finanzinstituten/Versicherungen recht wichtiges und eigentlich normales Vorgehen.
Viele Grüße,
Martin

[Martin Altmann]

Hallo Tom,

(der Urdatensatz bleibt erhalten, wird aber ausgeblendet, was man mit SET DELETED ON und einem einfachen Löschen auch erreichen kann)

Ohohohoh!!! Sehr gefährlich!! Gerade wenn man sehr "versierte" Anwender hat, die meinen, eine DBF-Datei muss man auch mal mit Access oder einem anderen Tool öffnen - wenn dann dort ein pack() abgesetzt wird ("packen ist doch gut, wird die Datei kleiner!"), sind die Daten futsch!

Viele Grüße,
Martin

[Manfred]

Das ist ja alles gut und schön.... AAaaaber.

Die DB wird ja auch nicht schneller, wenn die Anzahl der gelöschten Sätze steigt und schon gar nicht, wenn sie später übersprungen werden müssen. Außerdem kann in intensiv genutzten DB auch nicht unendlich viel gespeichert werden. Wie lange soll es denn dauern, bis die DB geöffnet wurde im Netz incl. Index usw.?

Also auf Anhieb würde ich sagen: Prima History. Aber Performance?

[Tom]

Hallo, Martin.

Gerade wenn man sehr "versierte" Anwender hat, die meinen, eine DBF-Datei muss man auch mal mit Access oder einem anderen Tool öffnen - wenn dann dort ein pack() abgesetzt wird ("packen ist doch gut, wird die Datei kleiner!"), sind die Daten futsch!

Geschenkt - die finden noch viel originellere Wege, Daten zu zerstören. Und um sich gegen sowas zur Wehr zu setzen, hilft es nur, Daten zu crypten oder z.B. die Dateiheader vor jedem Öffnungsvorgang zu verändern.

[Martin Altmann]

Hallo Manfred,

Die DB wird ja auch nicht schneller, wenn die Anzahl der gelöschten Sätze steigt und schon gar nicht, wenn sie später übersprungen werden müssen.

Für sowas gibt es ja scopes

Außerdem kann in intensiv genutzten DB auch nicht unendlich viel gespeichert werden. Wie lange soll es denn dauern, bis die DB geöffnet wurde im Netz incl. Index usw.?
Also auf Anhieb würde ich sagen: Prima History. Aber Performance?

Genau - darum nimmt man bei solchen Anforderungen dann auch lieber SQL! Da geht sowas recht flott.

Hallo Tom,

Geschenkt - die finden noch viel originellere Wege, Daten zu zerstören.

Jup - das sind dann die, die sowieso alles besser wissen Hat bestimmt auch jeder von uns wenigstens einen davon unter seinen Kunden...
Viele Grüße,
Martin

[Martin Altmann]

Hallo Tom,

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

es geht um den Eintrag Odd error am 24.11.2005 um 15:29 in der alaska-software.news.generic gestartet.
Dort kam durch Joe Carrick das Thema insofern hoch, als das scheinbar mit der 1.9 Version die Standardeinstellung von SET UNIQUE geändert wurde.

Viele Grüße,
Martin

[Armin]

huhu zusammen,

wow, so schnell so viele Nachrichten

zum Thema RECNO() in Indexdateien, bzw. möglichst eindeutige Indexdateien:

Da die Indexdateien als B*-Bäume funktionieren, hat man mit vielen gleichen Einträgen einen recht breiten Baum. In der Breite muss mehr oder weniger sequentiell gesucht werden. Wir suchen nicht nach RECNO() das ist nur eine Hilfe für die Indexdatei (schneller/ kleiner) - ANSONSTEN völlig unnötig. Nur als kleiner Tip, Indexdateien etwas schneller zu machen. RECNO() interessiert uns dabei nicht - es ist nur ein Trick - und L2BIN(RECNO()) ist halt weniger zu speichern als mit STR(RECNO())

Das hat auch nix mit PACK zu tun. Klar werden die Satznummern dann neu vergeben. Wir suchen dann mit SOFTSEEK, bzw.

z.B.
INDEX ON UPPER(ORT)+UPPER(STR)+UPPER(NAME)
oder
INDEX ON UPPER(ORT)+L2BIN(RECNO())

DBSEEK(UPPER(ORT),.T.)

zum Thema PACK

Ich benutze schon immer mit Erfolg und ohne Probleme PACK. Ich lösche ein Satz mit DELETE. Dadurch verschwindet er aus dem sichtbaren Bereich. Ich versuche exklusives Benutzen, wenn´s nicht geht, dann halt beim nächsten Mal.

zum Thema Orginaldatensatz aufheben

für jede Änderung einen eigenen Datensatz in der gleichen Datei anlegen - das geht nicht, würd viel zu viel werden. Ausserdem achte ich auch relativ normale Grössen der aktuellen Dateien - Performance.

Zum Zurückverfolgen könnte man die alten Sätze in einer Art Journal speichern. Für jede DB z.B. ein eigenes Journal.

Keine Änderungen im Originaldatensatz - ich denke, damit ist z.B. gemeint, dass Benutzer 1 den Satz auf den Bildschirm holt und einen Telefonanruf erhält, Benutzer 2 diesen Satz auch zum Ändern heran zieht und die Änderungen abspeichert. Benutzer 1 hat demzufolge den aktuellen Satz nicht auf dem Schirm.

Dazu speichere ich den Originalsatz in einem Array, lade ihn in Speichervariablen, gebe ihn zum Editieren und vergleiche vor dem Speichern den aktuellen Satz mit dem Satz im Array. Sind diese unterschiedlich, so hat ein anderer Benutzer in der Zwischenzeit diesen Satz geändert (entweder Hinweis, Speichern sperren, nochmals Originalsatz editieren...)

sodele, ach ja ich bin z.B. Engelsbrander

Armin

[Tom]

Hallo, Armin.

Da die Indexdateien als B*-Bäume funktionieren, hat man mit vielen gleichen Einträgen einen recht breiten Baum. In der Breite muss mehr oder weniger sequentiell gesucht werden. Wir suchen nicht nach RECNO() das ist nur eine Hilfe für die Indexdatei (schneller/ kleiner) - ANSONSTEN völlig unnötig. Nur als kleiner Tip, Indexdateien etwas schneller zu machen. RECNO() interessiert uns dabei nicht - es ist nur ein Trick - und L2BIN(RECNO()) ist halt weniger zu speichern als mit STR(RECNO())

Okay, dieses Argument kann ich nachvollziehen. Wobei sich ein Effekt, der den Verlust durch etwas den größeren Index ausgleicht, vermutlich erst bei relativ großen Datenmengen einstellt. Erfahrungen?

Ergänzung: Bei dieser Art von Nutzung spielt es dann natürlich auch keine Rolle, daß die Datensatznummer beim Packen oder Sortieren neu vergeben wird, solange man gleich im Anschluß reindexiert.

[Armin]

Hallo Tom,

ich habe die RECNO()-Erweiterungen wieder rausgeschmissen - hatte keine sichtbaren Effekte. Ich halte meine laufenden DBF´s in der Grössenordnung, dass ich auch noch FILTERN kann -

was ich viel drin habe sind die Teil-Stringsuchen mit FILTER

SET FILTER TO ORT$ADRESSEN->ORT

Nach dem PACK mache ich keinen REINDEX - ich habe meine Indedateien während des PACKs geöffnet.

Gruss, Armin

[Manfred]

Ich denke mal, da es zum Thema Index gehört, kann ich es hier hinten dran kleben.

Ich habe die Frage schon an Alaska gestellt, aber von dort keine Erklärung bekommen. Vielleicht hat sich hier schon jemand näher damit beschäftigt:

Wenn Xbase++ oder Clipper merkt, das der Index defekt ist, kann man dann nicht irgendwas bauen um einen Index zu prüfen. Natürlich unter Berücksichtigung des Zeitaufwandes, den eine Prüfung mit sich bringen würde. Also irgendwie nur ein paar Testzugriffe, oder so.

Weiß eigentlich jemand, wie die beiden Programme es überhaupt merken, dass ein Index defekt ist?

[Tom]

Hallo, Manfred.

Wenn Xbase auf einen korrupten Index "tritt", feuert (*) bei DBFNTX dieser Fehler: DBFNTX/1012, Corruption detected. Solche Fehler kann man in einer geänderten ERRORSYS.PRG abfangen - und, zum Beispiel, gleich ein Reindex auslösen.

Die Integrität von Indexen kann man theoretisch auch selbst testen. NTX ist ziemlich umfassend dokumentiert (z.B. im "Referenzhandbuch Dateiformate" von Günther Born). Eleganter ist es aber, einfach die ERRORSYS auf einen Reindex zu verbiegen.

*Leider erzeugt die 1.82 diesen Fehler nicht, sondern subsummiert - fehlerhafterweise - alle Indexfehler unter "Betriebssystemfehler 1, unzulässige Funktion". Das soll in der 1.9 wieder behoben sein.

[Manfred]

Hi Tom,

das hört sich gut an.

Jetzt stellt sich mir aber die nächste Frage dazu: Wenn der "Feuertritt" stattgefunden hat, ist es dann schon allerhöchste Eisenbahn? Mit anderen Worten folgendes Szenario:

Eine Indexdatei ist defekt. Es stehen irgendwelche falschen Zuordnungen drin. Bisher hat es aber wohl immer gepaßt. Heißt das dann, das alles nochmals gut abgelaufen ist, oder bedeutet das, dass es bisher eine wackelige Angelegenheit war? Also, in dem Index stand zwar ein falscher Record, aber der paßte gerade irgendwie mit oder zu dem, der angesprungen wurde und der falsche wurde geändert? Oder gibt es diesen Weg überhaupt nicht?

Ich hoffe ich habe jetzt nicht zu verworren gefragt?

Oder nochmals kurz gesagt: Die Sätze die trotz eines defekte Index gefunden werden, sind richtig, oder war es Zufall?

[Tom]

Hallo, Manfred.

Du stellst Fragen.

Ein Index enthält eine Referenz auf den korrespondierenden Datensatz UND den Wert des Feldes, auf das er verweist. Ich denke, Indexkorruptionen lassen sich u.a. in folgenden Fällen feststellen:

a. Der Wert im Index stimmt nicht mit dem Wert im Datensatz überein, obwohl auf diesen Datensatz verwiesen wird (Index war nicht aktiv, als die Datenbank aktualisiert wurde)
b. Der Datensatz, auf den der Index verweist, ist nicht vorhanden
c. Feld und Wert im Index haben unterschiedliche Typen
d. Der Index hat strukturelle Fehler, Daten werden nicht dort gefunden, wo sie erwarten würden

Link hierzu: Struktur einer NTX-Datei

Da Indexe m.E. immer nach der Datendatei aktualisiert werden, würde ich im Fehlerfall davon ausgehen, daß die DBF korrekt ist. Tatsächlich habe ich den umgekehrten Fall auch noch nie erlebt. Ein Reindex sollte alle Probleme beseitigen.

[Manfred]

Du stellst Fragen.

Ja ich weiß.....

Ich habe aber gewarnt....

Ein Index enthält eine Referenz auf den korrespondierenden Datensatz UND den Wert des Feldes, auf das er verweist. Ich denke, Indexkorruptionen lassen sich u.a. in folgenden Fällen feststellen:

a. Der Wert im Index stimmt nicht mit dem Wert im Datensatz überein, obwohl auf diesen Datensatz verwiesen wird (Index war nicht aktiv, als die Datenbank aktualisiert wurde)

das habe ich bisher selbst immer abgefragt, nervt aber ein wenig.

b. Der Datensatz, auf den der Index verweist, ist nicht vorhanden

naja, das gibt ein dummes Gesicht.

c. Feld und Wert im Index haben unterschiedliche Typen
d. Der Index hat strukturelle Fehler, Daten werden nicht dort gefunden, wo sie erwarten würden

hm...

Link hierzu: Struktur einer NTX-Datei

Werde ich mal lesen

Da Indexe m.E. immer nach der Datendatei aktualisiert werden, würde ich im Fehlerfall davon ausgehen, daß die DBF korrekt ist. Tatsächlich habe ich den umgekehrten Fall auch noch nie erlebt. Ein Reindex sollte alle Probleme beseitigen.

Ich glaube hier habe ich mich auch mal wieder undeutlich ausgedrückt. (Langsam wird das sehr bedenklich mit mir)

Was ich meinte war nur, ob die "gefundenen" denn dann wohl korrekt behandelt wurden, trotz defekten Index.

[Martin Altmann]

Hallo Manfred,
der Satz, der gefunden wurde, ist der aktuelle, auf dem auch gearbeitet wird!
Wurde also ein falscher gefunden, dann werden eventuell zurückzuschreibende Änderungen an diesem vorgenommen!
Viele Grüße,
Martin

[Manfred]

Hallo Martin,

hm, das würde ja bedeuten, dass zu einem defekten Index ein Satz gefunden wurde, der falsch ist, aber das Sytem es nicht merkt und ihn trotzdem ändert.

Schade schade schade.....

Nagut, lassen wir es bis hierhin reichen, das geht sonst ins endlose.

[Tom]

Wenn die im Index gespeichterten Werte des Schlüssels (Indexausdruck) nicht mit dem korrespondierenden Eintrag in der Datenbank übereinstimmen, also zwar ein Datensatz gefunden wird, er aber nicht den Wert des Schlüssels enthält, bekommt man einen Laufzeitfehler. Das kann man leicht ausprobieren, indem man mit einem (Hex-)Editor einen Index bearbeitet. Und deshalb wird der Datensatz auch nicht aktualisiert - es gibt vorher einen Laufzeitfehler. Man spricht in diesem Zusammenhang von korrupten Indexen.

[Manfred]

dann nehme ich das Schade Schade Schade zurück. Das ist dann o.K.

[Martin Altmann]

Hallo Tom,
bist Du Dir mit Deiner Aussage sicher?
Ich rede von Fall a)
Es wird der Ausdruck in der Indexdatei gesucht und gefunden. Die dort hinterlegte Datensatznummer wird angesprungen, da sie ja existiert (sonst wäre es ja Dein Fall b) ist doch für das System alles in Ordnung, oder nicht Eine weitere Prüfung findet doch nicht statt, erst beim Aktualisieren des Indexschlüssels wird doch wieder schreibend auf die Indexdatei zugegriffen, oder

Viele Grüße,
Martin

[Tom]

Hallo, Martin.

Ziemlich.

Im Index wird ein Datensatz gesucht (zunächst nur im Index, da dort ja der Wert gespeichert ist) und ein korrespondierender Datensatz wird gefunden (über die referenzierte Datensatznummer, die auch im Index steht). Der Wert in der Tabelle entspricht aber nicht dem zuvor gefundenen Wert im Index. Blubb, das Fehlersystem feuert. Probier's einfach aus.

[Martin Altmann]

Hallo Tom,
Dein Wunsch war mir Befehl - hier ein kleines Programm:

Code: Alles auswählen

astruct := { {"Name","C",10,0} }
dbcreate("bla.dbf", astruct)
use bla
append blank
bla->Name ="A: Erster"
append blank
bla->Name ="B: Zweiter"
append blank
bla->Name ="C: Dritter"
append blank
bla->Name =" : Nullter"
index on name to bla
go top
do while .not. eof()
	? recno()
	?? bla->name
	skip
enddo
close indexes
goto 4
bla->name := "D: Vierter"
go top
do while .not. eof()
	? recno()
	?? bla->name
	skip
enddo
set index to bla.ntx
go top
do while .not. eof()
	? recno()
	?? bla->name
	skip
enddo
go top
seek " : Nullter"
? found()
?? recno()
?? bla->name

Und hier die Bildschirmausgabe (die Leerezeilen habe ich nachträglich eingefügt, um die Zuordnung zu den ?-Anweisung optisch einfacher zu ermöglichen. Der erste Block ist die Reihenfolge mit aktivem Index. Danach wurde ohne die Indexdatei offen zu haben der vierte Datensatz geändert! Der zweite Viererblock ist die Reihenfolge ohne offener Indexdatei und der Dritte mit wieder geöffneter Indexdatei. Die letzte Zeile ist das Ergebnis des Seek-Befehls):

Code: Alles auswählen

              4 : Nullter
              1A: Erster
              2B: Zweiter
              3C: Dritter

              1A: Erster
              2B: Zweiter
              3C: Dritter
              4D: Vierter

              4D: Vierter
              1A: Erster
              2B: Zweiter
              3C: Dritter

J              4D: Vierter

Wie Du siehst (wenn Du es probierst), gibt es keinen Fehler.
Einfach mit xpp kompilieren und mit alink linken.
Ich habe also den Fall a) nachgestellt - Ändern eines (Index-)Feldes, ohne den Index aktiv zu haben.
Meine Xbase++-Version ist die 1.82.306 - das Verhalten kenne ich so auch noch von Clipper früher, aber es ist ja auch normal. Wie sollte es sich in diesem Fall denn auch sonst verhalten? Der Index wird ja gelesen und es wird (natürlich) auch kein Fehler gefunden.
Viele Grüße,
Martin

[Martin Altmann]

Hallo Tom und Manfred,
ich habe mein obiges Posting mal ein wenig (nachträglich) aufbereitet, so dass es besser lesbar sein sollte.
Dieses Posting schreibe ich nur, damit Ihr das auch mitbekommt

Viele Grüße,
Martin

[Manfred]

Hi Martin,

ich war mir gestern auch nicht so ganz sicher und habe deshalb nochmals ein wenig in alten Codes herumgestöbert. Dabei stieß ich dann auch auf meine Prüfroutine, ob der Index o.K. ist. Ich habe auch das Ergebnis mit den Suchkriterien verglichen, um eben zu verhindern, dass der Record zwar angesprungen wird, aber evtl. nicht dem Index entspricht. Und dann kam es mir auch langsam wieder ins Gedächtnis, das es des öfteren vorkam, dass zwar ein "Ziel" gefunden wurde, aber der Weg dahin nicht richtig war, sprich es war ein falsches. Dann kam eben eine Meldung von mir usw.

Kann man jetzt sagen, die Indexverwaltung ist nicht vernünftig durchdacht in dem Treiber, oder läßt es sich gar nicht besser lösen? So wie Tom es beschrieben hat sollte es doch ein leichtes sein im System selbst schon den Vergleich anzustellen: Was ist angesprungen worden und was wurde gefunden.

Fragen über Fragen

[Martin Altmann]

Hallo Manfred,
klar hätte man das einbauen können - war aber auch in Clipper schon nicht so (Xbase++: Clipperkompatibel!).
Außerdem wird es dadurch ja auch (ein wenig) langsamer, wenn immer erst nach einem vermeintlichen found() noch verglichen wird, ob das Ergebnis stimmt.
Aber genau das war nämlich mit ein Grund, warum ich bisher auf permanente Indexe verzichte! Schließlich gibt es ja immer Kunden, die "mal eben schnell" mit Excel/Access/... ein Feld editieren - und wenn dabei ein Schlüsselfeld geändert wird, hat man das o.g. Problem!
Ich hatte nach Toms AUssage schon Hoffnungen, dass sich da jetzt was getan gehabt hätte...

Viele Grüße,
Martin

[Manfred]

Hi Martin,

hm, irgendwoher muß Tom es ja haben, dass es so klappen sollte.

Warten wir einmal ab, was er zu seiner Verteidung zu sagen hat