Index Treiber
Moderator: Moderatoren
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Tom,
Viele Grüße,
Martin
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!Tom hat geschrieben:(der Urdatensatz bleibt erhalten, wird aber ausgeblendet, was man mit SET DELETED ON und einem einfachen Löschen auch erreichen kann)
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
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?
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?
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: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Hallo, Martin.
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.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!
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Manfred,
Hallo Tom,
Viele Grüße,
Martin
Für sowas gibt es ja scopesManfred hat geschrieben: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.
Genau - darum nimmt man bei solchen Anforderungen dann auch lieber SQL! Da geht sowas recht flott.Manfred hat geschrieben: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?
Hallo Tom,
Jup - das sind dann die, die sowieso alles besser wissen Hat bestimmt auch jeder von uns wenigstens einen davon unter seinen Kunden...Tom hat geschrieben:Geschenkt - die finden noch viel originellere Wege, Daten zu zerstören.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Tom,
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
es geht um den Eintrag Odd error am 24.11.2005 um 15:29 in der alaska-software.news.generic gestartet.Tom hat geschrieben:Das scheint mir ein etwas abstruser und recht unsicherer Weg zu sein, derlei zu erreichen.
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Armin
- Rekursionen-Architekt
- Beiträge: 394
- Registriert: Mo, 26. Sep 2005 12:09
- Wohnort: 75331 Engelsbrand
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
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
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
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Hallo, Armin.
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.
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?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())
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.
Herzlich,
Tom
Tom
- Armin
- Rekursionen-Architekt
- Beiträge: 394
- Registriert: Mo, 26. Sep 2005 12:09
- Wohnort: 75331 Engelsbrand
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
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
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
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
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?
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?
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: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
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?
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?
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: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Ja ich weiß.....
Du stellst Fragen.
Ich habe aber gewarnt....
das habe ich bisher selbst immer abgefragt, nervt aber ein wenig.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)
naja, das gibt ein dummes Gesicht.b. Der Datensatz, auf den der Index verweist, ist nicht vorhanden
hm...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
Werde ich mal lesenLink hierzu: Struktur einer NTX-Datei
Ich glaube hier habe ich mich auch mal wieder undeutlich ausgedrückt. (Langsam wird das sehr bedenklich mit mir)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.
Was ich meinte war nur, ob die "gefundenen" denn dann wohl korrekt behandelt wurden, trotz defekten Index.
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!!
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
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.
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.
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: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
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.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
dann nehme ich das Schade Schade Schade zurück. Das ist dann o.K.
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!!
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
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.
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.
Herzlich,
Tom
Tom
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Tom,
Dein Wunsch war mir Befehl - hier ein kleines Programm:
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):
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
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
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
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
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
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!!
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21224
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
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
hm, irgendwoher muß Tom es ja haben, dass es so klappen sollte.
Warten wir einmal ab, was er zu seiner Verteidung zu sagen hat
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!!