Noch einmal Index mit FOR-Klausel, anderes Problem

[Jan]

Ich hab ja neulichst mal gefragt wie man eine FOR-Klausel in einen Index einbaut. Nach entsprechenden Hinweisen habe ich das dann auch umgesetzt, und ansich klappt das auch einwandfrei. Ansich, denn jetzt habe ich ganz andere Probleme:

1) Wenn man eine Weile mit der Datenbank und dem aktiven Index gearbeitet hat, dann gibt es beim Blättern in DbEdit über BildAb/BildAuf diese Fehlermeldung:

Fehlermeldung.jpg (8.21 KiB) 5239 mal betrachtet

2) Der Index hat zwei FOR-Bedingungen drin:

Code: Alles auswählen

adressnr > 1 .AND. Empty(einbearb)

. Die zweite davon wird während des Bearbeitens in DbEdit angefasst, sprich, das Feld einbearb wird gefüllt. Damit müsste dieser Datensatz ja eigentlich aus dem Index rausfallen. Tut es aber nicht. Nach längerem Arbeiten bleiben diese Datensätze im DbEdit einfach stehen. Obwohl sie ja eigentlich lt. Index garnicht mehr angezeigt werden dürften.

Gibt es hier eventuell ein Problem mit wie damals mit dem UNIQUE, das mich auch zur Verzweiflung gebracht hatte?

Jan

[georg]

Hallo, Jan -


nehmen wir an, Dein Programm steht auf Datensatz 418. Dort wird das Feld gefüllt. Wenn der Satzzeiger nicht bewegt wird, bleibt der Satz in der Anzeige.

Eventuell könnte ein

Code: Alles auswählen

dbskip(1)
dbskip(-1)
oBro:refreshall()

helfen. So wie ich das verstehe, greift die Eingrenzung des Index erst dann, wenn der Satzzeiger bewegt wird.

[Jan]

Hallo Georg,

kann ich mal versuchen.

Aber ich habe gerade ein ganz anderes Problem entdeckt: Der Index ist frisch nach dem Aufbauen ca. 65 KB groß. Jetzt aber 1,6 GB!

Jan

[georg]

Hallo, Jan -


Indexe "vergreisen" schon mal, daher sollte man sie regelmässig neu aufbauen.

Aber Dein Beispiel ist schon extrem, das muss ich zugeben!

[Jan]

Vergreisen ist gut! Innerhalb von 16 Stunden (davon nur 3 Stunden in Bearbeitung) von 65 KB auf 1,6 GB? Tolle Zeitmaschine.

Jan

[Koverhage]

Ist halt Alaska Zeitmaschine

[Tom]

Vielleicht aktualisierst Du im Rahmen der Darstellungs-/Bearbeitungsroutine fälschlicherweise ständig irgendwelche Inhalte.

[brandelh]

Wobei dies aber Inhalte mit Bezug auf den Indexschlüssel sein müssten.

[Tom]

@Hubert: Ja, logisch. Aber es hört sich tatsächlich so an, als gäbe es bei jedem DbSkip() irgendwelche Replace-Operationen. Vielleicht ist da bei einer Vergleichsoperation irgendwo ein Doppelpunkt reingerutscht (IF <fieldvar1> := <fieldvar2> statt IF <fieldvar1> == <fieldvar2>). Dadurch nicht nur das Anwachsen des Indexes (CDX, richtig?) zu erklären, sondern auch das vermeintliche Scheitern der FOR-Bedingung.

[Jan]

Hallo Tom,

nein, DbfNtx. Das macht es etwas komplizierter, denn damit habe ich weit weniger Erfahrungen als mit FoxCdx. Wobei sich das ja eigentlich zumindest in diesem Bereich identisch verhalten sollte.

Jan

[Tom]

Hallo, Jan.

NTX-Indexe wachsen nicht - oder nur sehr marginal; den Zwang, sie vor dem Reindexieren zu löschen, gibt es also genau genommen nicht. Die Ursache kann also nicht hier liegen. Klingt dann eher nach einem physischen Problem - defekter Festplattencontroller oder so. Oder Du schreibst versehentlich etwas in die Indexdatei, obwohl Du glaubst, eigentlich ganz woanders hinzuschreiben.

[Tom]

Hinweis: Mit den "Sysinternals"-Tools (www.sysinternals.com, ist eine Microsoft-Firma) kann man Prozesstätigkeiten überwachen, aber auch beispielsweise Verzeichnisse und einzelne Dateien, also - etwa in "Process Monitor" - sehen, welcher Prozess wann auf welche bestimmte Datei zugreift und was er mit ihr anstellt. Damit sollte es, wenn sich das Verhalten replizieren lässt, möglich sein, herauszufinden, wie und wodurch das Anwachsen der Indexdatei ausgelöst wird.

[Jan]

@Hubert: Ja, logisch. Aber es hört sich tatsächlich so an, als gäbe es bei jedem DbSkip() irgendwelche Replace-Operationen. Vielleicht ist da bei einer Vergleichsoperation irgendwo ein Doppelpunkt reingerutscht (IF <fieldvar1> := <fieldvar2> statt IF <fieldvar1> == <fieldvar2>). Dadurch nicht nur das Anwachsen des Indexes (CDX, richtig?) zu erklären, sondern auch das vermeintliche Scheitern der FOR-Bedingung.

Hallo Tom,

das habe ich gerade mal überprüft. Ist aber nicht so. Das hätte mich auch gewundert, denn der Code ansich lief immer einwandfrei. Ich habe jetzt nur den Index geändert, indem ich die FOR-Klausel eingebaut habe. Und genau seitdem läuft das unrund.

Jan

[Manfred]

Bau doch mal die Sache nur mit Index on.... ein und schaue Dir mal an, was der PPO daraus macht. Vielleicht gibt es da ja doch einen Unterschied?

[AUGE_OHR]

hi,

bei NTX : wie sieht bei dir

Code: Alles auswählen

SET OPTIMIZE <OFF / on>

aus ?

wird während des Bearbeitens in DbEdit angefasst, sprich, das Feld einbearb wird gefüllt

und das vermutlich in der UDF ... und dann ? welcher RETURN Value ?

@georg : wir reden hier von DbEdit ... nicht Tbrowse oder XbpBrowse wo es ein "refresh" gibt.