Richtiges Löschen von Datensätzen

[Kolben]

Guten Tag zusammen!

Ich bin ganz neu in xBase & Co, habe bisher ausschließlich viel in Access etc gearbeitet.

Ein aktuelles Anliegen habe ich: Wenn ich Daten in einer Tabelle lösche, sind die Daten denn dann auch wirklich gelöscht? Gibt es irgendeine Möglichkeit, diese wiederherzustellen oder zu sehen, dass Datensätze gelöscht wurden? Nach dem Löschen führe ich immer den Befehl "Pack" aus, um die fortlaufende Nummer neu zu generieren.

Danke für die Hilfe!

Max aus Regensburg

[Jan]

Hallo Max,

herzlich willkommen hier im Forum. Vielleicht magst Du Dich kurz vorstellen weiter unten in den Unterforen "Guten Tag ich bin... "?

Zuerst ein inzwischen lästiger Hinweis: Das Produkt heißt Xbase++. Großes X, kleines b.

Und ja, wenn Du nein Pack gemacht hast, dann sind die Daten unwiederbringlich weg.

Jan

[Manfred]

Hallo Max,

bei einem Delete wird der Satz nur als gelöscht gekennzeichnet, bleibt aber erhalten und kann mit einem Recall wieder "zurückgeholt" werden. Mit Set DELETE ON/OFF kann die Sichtbarkeit des gelöschten Satzes manipuliert werden. Erst nach einem PACK (Exclusiver Zugriff Voraussetzung) wird der gelöschte Satz richtig entfernt.

[Kolben]

Mach ich, hatte ich in der Eile nur nicht gemacht. Danke

[brandelh]

wobei PACK aus mehreren Gesichtspunkten heraus problematisch ist

Wenn du eine Einzelplatzanwendung mit exklusivem Zugriff schreibst, dann ist PACK ok, aber ...
Pack nimmt gültige Datensätze von hinten und überschreibt den Platz von gelöschten.
Ob er dann am Ende tatsächlich den Inhalt von der Festplatte löscht oder nur das Dateiende verkürzt (das vermute ich)
ist nicht klar.

Wenn deine Frage also war, ob alle Daten zuverlässig weg sind, so ist das nicht immer gewährleistet.
Aus der Anwendung heraus sind sie weg.

Im Netzwerk oder mit gemeinsamem Zugriff ist PACK nicht zu empfehlen, da
1. PACK braucht EXCLUSIVE, somit muss man im Netz alle aussperren und die müssen warten.
2. Wenn ein Netzwerkfehler auftritt ist die Datei in einem nicht definierten Zustand !
3. Im Netz ist es langsam ...

Im Netz recycled man gelöschte Datensätze und nutzt eine Kombination von COPY FOR NOT DELETED() und RENAME um das sicher zu machen.

Jetzt klären wir zu erst was du wirklich brauchst

[Tom]

Ich bin da nicht Huberts Meinung.

Zunächst einmal erzeugt DbPack() tatsächlich eine temporäre Kopie der Tabelle, vermutlich auf einem ähnlichen Prozess wie "COPY TO ... FOR !Deleted()" basierend. Das kann man sogar sehen, denn die temporären Dateien entstehen im Zielverzeichnis ("xpp99E7.tmp" o.ä.). Erst nach der erfolgreichen Kopie wird das Original gelöscht und die temporäre Datei wird umbenannt. Dieser Vorgang ist meiner Erfahrung nach absolut verlässlich. Ich nehme an, dass er für den Fehlerfall auch entsprechend gekapselt ist, denn wir haben es noch niemals erlebt, dass im Rahmen eines DbPack() Tabellen verloren gegangen sind.

Ein DbPack() von Tabellen, die im Netz konkurrierend genutzt werden können, sollte natürlich nur ausnahmsweise erfolgen, also im Servicefall ("Datenreorganisation"). Ansonsten kann man natürlich, wenn es anderswo erforderlich wird, mit exklusivem Zugriff, NetErr() und entsprechenden Informationsmechanismen hantieren. Beim Versuch, Tabellen im Netz zu öffnen, sollte ohnehin standardmäßig NetErr() abgefragt werden, weil es, von DbPack() abgesehen, auch andere Szenarien gibt, in denen exklusive Verwendung nötig ist (Reindexierung u.ä.), davon abgesehen gibt es auch Störungen von außen (Tabelle wird mit Excel geöffnet, gerade gesichert oder so).

Ach so:

Im Netz ist es langsam ...

Alle Dateioperationen im Netz, die auf exklusiv geöffneten Tabellen stattfinden, sind deutlich schneller als solche, die auf konkurrierend geöffneten Tabellen ausgelöst werden. Das fängt bei simplen Dateinavigationen an (kann man ziemlich leicht nachstellen und prüfen) und endet längst nicht bei komplexen Operationen. Natürlich ist es grundsätzlich langsamer, wenn man im Netz etwas auf einem Massenspeicher tut, aber keinesfalls drastisch langsam. Wir haben eine Zeit lang versucht, in solchen Situationen lokale Kopien von Tabellen anzulegen, um den Vorgang zu beschleunigen, aber der marginale Gewinn wird durch die Kopieroperationen wieder fast gänzlich aufgefressen. Und außerdem entsteht eine große Verzögerung tatsächlich erst bei sehr großen Tabellen. Ein DbPack() auf einer Tabelle mit 100.000 Datensätzen und 50, 100 Spalten dauert selten länger als ein, zwei Minuten maximal.

Wo wir beim Thema sind: Problematisch ist DbPack() im Kontext von Tabellen mit Memofeldern, da diese nicht angefasst werden. Um Memodateien von gelöschten Datensätzen zu befreien, muss man tatsächlich mit DbExport() (COPY TO) arbeiten und anschließend Tabellen umbenennen (oder wieder importieren, was aber unnötige Zeit kostet).

[brandelh]

Zunächst einmal erzeugt DbPack() tatsächlich eine temporäre Kopie der Tabelle, vermutlich auf einem ähnlichen Prozess wie "COPY TO ... FOR !Deleted()" basierend.

wenn das so ist, ist Xbase++ tatsächlich sicherer als es Clipper war (oder war das gar dBase ... ich habe es jedenfalls anders gehört)
Ich nutze schon lange ein Recycling Verfahren und nur sehr selten die Copy to Methode, genau die Memodateien ... das Argument hatte ich vergessen.

Es gibt aber tatsächlich Anwendungen die immer alle Dateien offen haben und wer möchte schon Wochenenddienst schieben

[Koverhage]

Hubert,

was meinst Du damit ?

Es gibt aber tatsächlich Anwendungen die immer alle Dateien offen haben und wer möchte schon Wochenenddienst schieben

[Tom]

Es gibt aber tatsächlich Anwendungen die immer alle Dateien offen haben und wer möchte schon Wochenenddienst schieben

In der Situation gibt es aber überhaupt keine Lösung. Wenn Tabellen quasi nie geschlossen werden, kann man sie natürlich nicht packen, aber mit einem DbExport() und anschließendem Umbenennen landet man genauso auf der Fresse.

Wir haben ein ziemlich komplexes und ausfallsicheres An-/Abmeldesystem, das auch etwaige Fehlersituationen sauber reflektiert, so dass die Applikation und dazugehörige Tools jederzeit wissen, ob jemand im Programm arbeitet. Es gibt Sperrsysteme, die den Aufruf im Servicefall verhindern und sogar darüber Auskunft geben, wie lang der Servicefall voraussichtlich noch dauern wird. Wir haben eigene Scheduler/Servicetools, die als Dienste installiert werden können und automatisch solche Funktionalitäten ausführen, natürlich die Anmeldesituationen reflektierend. Es gibt sogar ein manuelles Sperrsystem für bestimmte Tage und Uhrzeiten, das auch automatisch mit dem Sicherungssystem synchronisiert werden kann. Und so weiter. Wenn man mit physischen Tabellen und Indexen arbeitet, muss man hin und wieder packen und reindexieren, nicht zuletzt aus Performancegründen. Daran führt fast nichts vorbei.

[brandelh]

Als ich noch so eine Anwendung zu betreuen hatte, die von 6 Außenstellen und intern von gut 30 Mitarbeitern genutzt wurde, blieb nichts anderes übrig als Abends zu bleiben bis der letzte Abgemeldet war oder eben ein "Wartungswochenende" einzulegen. Das war aber eine 1:1 Portierung eines alten Clipper Programmes und dort blieb man wegen dem knappen Speicher unter DOS nur drin solange man es brauchte.
Das Problem kam erst mit NT, da dann jeder Morgens reinging und erst Abends raus - oder gar nicht.

Für den HOST waren "Wartungswochenende" immer normal, aber ich wollte das nicht
Später habe ich dann eingebaut, dass ich per FLAG die Anwendung stoppen konnte, was ich ab 17:00 Uhr getan habe.
Bei allen modernen habe ich aber überhaupt keine Dateien mehr offen, das kommt aber auch auf die Art der Anwendung an, ob das möglich ist.

[Tom]

Um mal auf Max' Ausgangsfragen zurückzukommen:

1. Xbase++ erzeugt beim DELETE / DbDelete eine Löschmarkierung. Unter normalen Bedingungen bleibt der Datensatzzeiger übrigens auf diesem Datensatz stehen - man sieht auch seine Daten noch, selbst wenn SET DELETED auf ON steht. Erst nach einer anschließenden Navigation, Neuöffnung der Tabelle oder ähnlichen Operationen verschwindet er aus der Sicht (und damit beispielsweise auch aus einem DB-Browse, auf dem RefreshAll() ausgelöst wird). Der Datensatz wird nicht physikalisch gelöscht.

2. Ob man gelöschte Datensätze nach der anschließenden Navigation oder beim abermaligen Aufruf der Tabelle sieht, hängt von SET DELETED ab - bei "ON" sieht man sie nicht, bei "OFF" werden sie wie ganz normale Datensätze behandelt. In dieser Situation lässt sich über Deleted() abfragen, ob ein Datensatz gelöscht ist oder nicht. In Standardanwendungen arbeitet man sicherlich mit SET DELETED ON. Man schaltet das nur ab, um beispielsweise versehentlich gelöschte Datensätze zu restaurieren. Oder in Servicetools, wo man dann die Löschmarkierung als Spalte in einer Tabellenansicht zeigen kann, wenn man will.

3. Das Gegenkommando zu DELETE lautet RECALL, die Gegenfunktion zu DbDelete() dementsprechend DbRecall. Die Kommandos können um Konditionen erweitert werden (FOR, WHILE). RECALL ALL entfernt die Löschmarkierungen von allen Datensätzen.

4. PACK/DbPack() entfernen gelöschte Datensätze physikalisch aus der Tabelle. Sie sind dann auch nicht mehr restaurierbar. Dies gilt nicht für Memofelder, die man in dieser Situation allerdings nicht mehr erreichen kann.

5. Wenn man in Netzwerkanwendungen Zähler setzen will, die eindeutig fortlaufend sind, muss man beachten, dass das konkurrierend gleichzeitig geschehen kann, so dass die Zähler nicht wirklich eindeutig sind. Sinnvoller ist es deshalb, beispielsweise Tabellen anzulegen, die die Zähler verwalten. Das gleichzeitige Hochsetzen verhindert man, indem man den entsprechenden Datensatz sperrt und das Durchschreiben der Tabelle mit DbCommit() erzwingt.

6. Alle DBF-Tabellen enthalten sowieso einen eindeutigen Zähler, nämlich die Datensatznummer, an die man mit RecNo() kommt. Die verändert sich allerdings, wenn Datensätze gelöscht werden, weshalb sie als eindeutiger Schlüssel nicht verwendet werden sollte.

[Manfred]

5. Wenn man in Netzwerkanwendungen Zähler setzen will, die eindeutig fortlaufend sind, muss man beachten, dass das konkurrierend gleichzeitig geschehen kann, so dass die Zähler nicht wirklich eindeutig sind. Sinnvoller ist es deshalb, beispielsweise Tabellen anzulegen, die die Zähler verwalten. Das gleichzeitige Hochsetzen verhindert man, indem man den entsprechenden Datensatz sperrt und das Durchschreiben der Tabelle mit DbCommit() erzwingt.

Hi Tom,

wenn ich Dir sonst zustimme, aber dabei muß ich leider meine Bedenken einwerfen. Ein Dbcommit() hilft da gar nicht auch keine Skip(0) oder so.. Ich bin erst glücklich geworden, nachdem ich besagte Zählerdatei exclusiv geöffnet habe, die Nummer wegschreibe und dann wieder schließe. Alles andere gab nur Ärger und Inkonsistenzen. Es wurde nie garantiert die letzte Nummer geschrieben, wenn ein anderer Arbeitsplatz evtl. nahezu gleichzeitig auch schreiben wollte.

[Tom]

Hallo, Manfred.

Du hast recht. Tatsächlich verfahre ich auch so. Die Zählerdatei wird erst geöffnet, wenn das exklusiv möglich ist, kurz aktualisiert und gleich wieder geschlossen. In allen anderen Situationen muss man damit rechnen, dass die Daten nicht aktuell sind.

[Herbert]

Sehr schön verfasst, Tom =D>

Zu ergänzen ist die Tatsache, dass normalerweise nicht sehr viel Datensätze als gelöscht rumschlummern. Wohl unter 10%, was für die Performance wohl nicht entscheidend sein wird.
Durch Programmierung kann man minimieren helfen (z.B. bei Neuanlegen eines Kunden und vor dem Sichern bricht der User ab), kann aber nicht verhindern, dass die Anwender durch unpräzises Arbeiten Löschungen provozieren.
Wartungsdinge, wie auch von Tom beschrieben, können so eine Bereinigung punktuell vornehmen, was längstens genügt. Bei uns ist das z.B. eine Archivierungsfunktion, welche alte Daten weglagert (viel grösseres Potential als gelöschte Einträge!) und zeitgleich gelöschte Sätze entfernt.

[Herbert]

Ich bin erst glücklich geworden, nachdem ich besagte Zählerdatei exclusiv geöffnet habe, die Nummer wegschreibe und dann wieder schließe. Alles andere gab nur Ärger und Inkonsistenzen. Es wurde nie garantiert die letzte Nummer geschrieben, wenn ein anderer Arbeitsplatz evtl. nahezu gleichzeitig auch schreiben wollte.

Du Glüclklicher

Also, diese Kontrolle muss beim Speichern erfolgen. Seek auf die ID, wenn gefunden, war ein anderer schneller und meckern oder verändern.

SQL übernimmt ja so was...
Die Lösung dazu wäre übrigens ein Feldtyp namens "automated ID", die bei einem anderen Compiler vorkommt

[Jan]

Ich habe einen Kunden, bei dem ständig Sätze angelegt und gelöscht werden. Die haben früher jede Woche gepackt. Ich habe das dann so umgeschrieben, das gelöschte Sätze (nur mit DbDelete()) komplett gelehrt werden, und beim Neuanlegen geschaut wird, ob es einen leeren Satz gibt. Wenn ja, wird der genutzt. Nur wenn nein, dann wird Appended. Seitdem haben wir glaube ich nur noch ein oder zwei mal gepackt, aber aus ganz anderen Gründen.

Jan

[Jan]

Herbert,

in FOXCDX gibt es solch ein Feld. Typ S. Das funktioniert ganz gut. Natürlich nicht ganz so sicher wie SQL, da die Kontrolle der DBF von mehreren Clients aus gesteuert wird und nicht vom SQL-Service. Aber es klappt gut.

Jan

[Herbert]

Was aber auch recht heikell ist, Jan (und auch Hubert). Denn gerne bleiben Daten des bestehenden Satzes irgendwo zurück. Eventuell in anderen verbundenen Tabellen.
Ich rate davon ab.

[brandelh]

Welche Daten sollten "übrig bleiben" ?
Natürlich lösche ich alle Felder eines Satzes (1 to fcount()) und natürlich muss man auch Kinddateien anpassen (aber das bei jedem Löschen)
Was auch nicht geht ist eine Referenz auf recno() zu speichern, aber das geht bei PACK auch in die Hose ...

Wenn man es richtig macht, funktioniert das recyclen wunderbar

PS: Ich wollte oben TOM nicht widersprechen, dass PACK nun eine temporäre Datei anlegt war mir neu und ist beruhigend.

[AUGE_OHR]

TMP=<Verzeichnis>

Im TMP Verzeichnis werden temporäre Dateien angelegt, z.B. wenn INDEX ON oder DbSort() ausgeführt wird.

das gilt IHMO auch für PACK

[Rolf Ramacher]

Hallo Jan

was ist Typ S bei Foxcdx ? was kann ich damit erreichen ?

[Jan]

Rolf,

hatte ich doch geschrieben. Damit wird bei jedem neuen Satz ein eindeutiger laufender Zähler mitgeführt. Uabhängig von RecNo().

Aber Achtung: Es gibt seit meiner Meldung an Alaska vor ca. 5 Jahren einen noch immer nicht geschlossenen PDR dazu. Liest man eine bestehende Datenbankstruktur ein mit einem S-Feld, und erzeugt aus dem Struktur-Array eine neue dbf, dann stimmt das Feld nicht mehr. Aber ansonsten klappt das sehr stabil und sicher.

Jan

[Rolf Ramacher]

Hi Jan

danke für den Hinweis. Vielleicht kann ich es mal gebrauchen.