Inoffizielles deutsches Xbase-Forum

Gestern hatte ich bei einem Kunden ein interessantes Phänomen: Ich hatte in einer dbf mit insgesamt ca. 6.200 Datensätzen bei ca. 6.100 Datensätze die Feldinhalte geleert und dann den Satz deleted. Soweit so OK.

Dann kam aber das Überraschende: Diese dbf inkl. der sechs dazugehörigen NTX zu öffnen dauert normalerweise ein Fingerschnippen. Nach der Löschaktion dauerte das plötzlich mehrere Minuten. Erst als die dbf gepackt worden ist, lief die wieder schnell.

Ist jemandem von Euch bekannt, das solche Löschaktionen derartige Auswirkungen haben können?

Jan

Was genau hat so lange gedauert ?

Wenn du SET DELETED ON und einen Browser hast, dann ist das verständlich, das er sequentiell erstmal viele Datensätze überspringen muss, bis er die 100 anzeigbaren hat.
Seltsam wäre es aber wenn es schon beim Öffnen ohne Anzeige länger dauert.

Hallo Hubert,

klar, wenn ich da einen browse drauf setzen würde, dann würde ich das ja noch verstehen können. Aber ein einfaches USE? Ich hab sowas noch nie gehört.

Jan

Ich auch nicht, allerdings habe ich auch selten solche Dateien (die hätte ich gepackt).

Das USE selbst sollte diese Wirkung nicht haben, denn USE bewegt/setzt eigentlich nicht den Dateizeiger. Da müsste schon irgendwo ein DbGoTop() sein. Das hätte zur Folge, dass der erste nichtgelöschte Datensatz gesucht wird.

es liegt ja vermutlich nicht am Use selbst, sondern an den Index Dateien.
Wenn es viele gelöschte Sätze in einer DBF mit Index Dateien gibt, kann das schon mal vorkommen.

Hallo Tom,

das passierte definitiv beim USE inkl. Index-Öffnen. Alles andere kann ich ausschließen.

Jan

Ein USE mit INDEX setzt den Dateizeiger auf den ersten Datensatz gemäß führendem Index. Dabei wird so lange geskippt, bis ein nichtgelöschter Datensatz gefunden wird, wenn SET DELETED auf ON steht. Workaround: Ein konditionaler Index mit FOR !Deleted().

mit oder ohne SET DELETED ON ?

Trenne die Öffnung der Indexdatei vom USE ab und du siehst wo es dauert !

USE // macht nichts, das müsste schnell gehen.
SET INDEX TO // hier kommt es auf die Einstellung von SET DELETED an !

mit SET DELETED OFF wird ein einfacher DbGoTop() implizit durchgeführt und der nach dem index kleinste Satz genommen. FALLS die 6000 mit blankem Indexfeld hast könnte das auch hier stören.

mit SET DELETED ON wird auch DbGoTop() schnell durchgeführt, danach muss aber intern ein dbLocate() auf den ersten Satz mit ! deleted() durchgeführt werden - das dauert. 6000 gleiche Indexfelder können zusätzlich bremsen.

Das Problem kenne ich auch. Öffnen mit Index und großer Zahl gelöschter Sätze erfordert Zeit. nach eine Pack geht es wieder ratz fatz.

Wie gesagt: Index mit "FOR !Deleted()"-Bedingung.