Inoffizielles deutsches Xbase-Forum

Das ist ja weder Fisch noch Fleisch...
Da ich sowieso mit SET DELETED ON arbeite, sollte das prinzipiell nicht so ein großes Problem sein.
Aber: Das führt dazu, dass LastRec() nicht die höchste RecNo() liefert, sondern nur die Anzahl der (nicht gelöschten) Datensätze.
Dadurch bekam ich z.B. Probleme in einer "Datensätze markieren" Funktion, die die markierte Datensätze bitweise abbildet...
Werde ich mit einer SELECT MAX(__record)... umgehen.
Also alles nur zur Info, aufpassen Leute!

Hallo David,
ich verstehe das Begehr noch nicht. Worauf muss man aufpassen?
Bedeutet aufpassen auch, dass das ein Fehler ist? Dann bin ich hoch daran interessiert.
Grüße, Frank

Hallo Frank,
ja, ich werde es nach dem Mittagessen als Fehler melden (bin gerade fertig mit Workaround).
Laut Hilfe:

LastRec() determines the record ID of the last record in a work area

Das ist in diesem Fall nicht so.

Es ist meiner Meinung nach noch unklar, ob Upsize die DELETED Datensätze hätte so weglassen dürfen, vielleicht kommen andere Probleme dadurch.
Da wir aber vor haben ab Montag (nach ca. 2 Jahren Vorbereitung) mit unserer konvertierten Datenbank in den Live-Betrieb zu gehen, bleibe ich erstmal bei meinem Workaround.

Ich glaube, David meint, dass beim Upsizing mit gelöschten Datensätzen und SET DELETED ON die Datensatznummern nicht recycelt werden, sondern sozusagen Löcher entstehen, also __recnos in der Zieltabelle fehlen. Die aber m.E. mit dem nächsten DbPack wieder weg wären.

Hey David,

ich habe noch kein kleines Beispiel dafür geschrieben (und nicht selbst geprüft), aber ich verstehe dich so (könnte auch unabhängig vom Upsize sein, oder?), dass LastRec() in einer Tabelle mit gelöschten Records "nur die Anzahl der (nicht gelöschten) Datensätze" zurückgibt. Das wäre natürlich falsch.

Diese Aussage "Upsize überträgt nicht DELETED Datensätze, behält aber die alte RecNo() in __record!" soll heißen, dass die DELETED markierten Sätze der DBF nicht übertragen werden? Aber brav die Recno()s übertragen werden, als wenn die DELTED Records noch vorhanden wären. Und das führt - wie Tom sagt - zu Löchern in der Nummerierung?

Interessant. Ja, bitte melden oder ich schreibe ein Beispiel dafür. Wäre nämlich ein Fehler.
Als Workaround könnte man ja nach dem Upsize ein dbPack() machen, oder? Würde das helfen? Finde ich auch heraus.

Grüße, Frank

Hello Frank,

ja, Tom hat den Fall korrekt beschrieben.
Soweit wie ich weiß, werden gelöschte Datensätze korrekt mitgezählt.
Nur wenn sie "physikalisch" fehlen, entsteht das Problem.
In der Hilfe werden übrigens LastRec() und RecCount() gleichgesetzt (außer, dass RecCount() "deprecated" wird).
Theoretisch sollten sie aber meiner Meinung nach in diesem Fall unterschiedliche Werte liefern...

Was das Packen angeht: Ich hatte sogar früher vor dem Upsize ein PACK gemacht.
Erst vor ein paar Tagen aber hat ein Tester bei uns entdeckt, dass einige Datensätze (kein Muster erkennbar) verschwunden sind.
Es muss irgendwelches Index-Problem gewesen sein, aber ich habe es nicht rechtzeitig finden und korrigieren können, deshalb habe ich das PACK entfernt.
Nur als Hintergrund, tut eigentlich nichts zur Sache.
Die Idee, ein PACK nach dem Upsize zu machen, finde ich prinzipiell gut.
Ich habe nur jetzt gerade ein bisschen Angst davor, so kurz vor der Inbetriebnahme, falls z.B. auch in diesem Fall irgendwelche Datensätze verschwinden.
Heute/morgen könnte ich es probieren, nur das Testen macht mir Sorgen, aber (ich denke laut) vielleicht reicht es wenn ich für jede Tabelle ein COUNT davor/danach mache...

Ich habe nochmal versucht, das PACK (vor dem Upsize) zu machen, was auch manche Datensätze ohne DELETED permanent gelöscht hat.
Wenn das funktionieren würde, wäre das die sauberste Lösung.
Es wird aber nun wirklich seltsam!
Ich habe eine DBF als Zip hochgeladen um das Problem zu zeigen.
Zum Beispiel, der 10. Datensatz (PLGRP=10, BEZ_E="CALIBRATORS") ist nicht als DELETED markiert (auch die 11. und 12. Datensätze nicht).
Das sehe ich sogar auch mit einem ganz anderen Werkzeug ("DBF Manager").
Ob ich mit Xbase++ oder DBF Manager PACK mache, Datensätze 10 bis 12 sind dann weg!
Es hat also nichts mit Indexen oder meinem Code rund um dem PACK zu tun, so wie ich vermutet hatte.
Ist das Problem bei Euch auch nachvollziehbar?

Hallo David

wenn ich Deine DBF mit 64 Sätzen 4 gelöschten mit Xbase dbu packe habe ich noch 55 Sätze

Kopiere ich die Datei mit dbu und packe die Kopie --> 60 Sätze

Filter mit deleted() funktioniert.

Die Orginal Datei hat 8.162 Zeichen die Kopie 8.163 Zeichen.

Hallo David !

Ich habe auch getestet:
- Die CDX fehlt.
- Die Sätze 31, 40, 45 und 46 sind zum Löschen markiert.
- Nach dem ZAPPEN fehlen genau diese 4 Datensätze.
Meine DBF-Tools:
- Semware-Editor mit DBF-Macro: - stBrowse:

Ob ich mit Xbase++ oder DBF Manager PACK mache, Datensätze 10 bis 12 sind dann weg!
Es hat also nichts mit Indexen oder meinem Code rund um dem PACK zu tun, so wie ich vermutet hatte.

Verstehe ich nicht.
Packe die CDX-Datei bitte noch dazu.

Hallo Bernd,
vielen Dank, das ist genau das Verhalten, es sollten 60 Datensätze geben und nicht nur 55.
Was meinst Du mit Xbase dbu? Das klingt wie ein nützliches werkzeug, was ich nicht kenne.

Hallo Hans-Peter,
Dir auch vielen Dank.
Ich habe die CDX nun auch als Attachment hinzugefügt.
Eine DBF enthält aber keine Hinweise auf dazugehörige Index-Dateien, oder?
Es war für mich interessant zu wissen, dass wie Bernd gezeigt hat, es dieses unstimmiges Verhalten auch mit nur der DBF gibt - dass in der DBF manche Datensätze nicht DELETED sind aber trotzdem nach PACK verschwinden.
Es scheint als ob die DBF auf einer seltsamer Art korrupt ist - meine Fragen wären dann, kann ich von vornerein feststellen ob auch andere DBFs betroffen sind ohne ein PACK zu machen, und wie kann ich sie reparieren?
Zur 2. Frage scheint Bernd schon eine Antwort gefunden zu haben, wenn ich nur wüsste was mit "Xbase dbu" gemeint ist...

Hallo David !

Eine DBF enthält aber keine Hinweise auf dazugehörige Index-Dateien, oder?

Aber klar doch und noch mehr; lese zu Versatz in Bytes bei 28 nach. Aber auch mit Index-Datei putzt mein VFP-Tool stBrowse die gleichen Datensätze weg - also diejenigen, die zum Löschen markiert sind.

Hallo Hans-Peter,

vielen Dank, das hätte ich nicht gedacht!
Da ist wahnsinnig viel da drin, ziegt von der bunten DBF-Geschichte...

Wegen des Projektstands bei uns muss ich aber nun einen anderen Weg gehen und werde vermutlich nicht mehr mit den DBFs arbeiten.
Falls ich noch einmal ein Upsize machen darf, dann mache ich vor dem Aufruf ein SET DELETED OFF - ich hoffe, dass DbfUpsize() dann auch die zum Löschen markierte Datensätze mit übernehmen wird.
Falls nicht, oder irgendwann danach falls doch, probiere ich wie von Tom vorgeschlagen ein PACK über PGDBE.
Ich habe sonst wenigstens das Workaround mit SELECT MAX(__record)... anstatt LastRec().

Ich danke Dir und Bernd nochmal für Eure Zeit und Mühe, da habe ich auf alle Fälle etwas gelernt, und seid bitte nicht böse mit mir, dass ich den Weg mit den DBFs vermutlich nicht weiter verfolge!

Hallo Frank,

das Problem kann von mir aus heruntergestuft werden, ich mache nun SET DELETED OFF vor DbfUpsize() und siehe da, die zum Löschen markierte Datensätze werden auch übertragen und alles ist stimmig.

Vielleicht wäre ein Hinweis in der Dokumentation (Hilfe) ausreichend, dass DbfUpsize() nicht mit SET DELETED ON benutzt werden soll, obwohl es natürlich schöner wäre, wenn DbfUpsize() die Satznummern in dem Fall "verdichten" würde.