Richtiges Löschen von Datensätzen
Moderator: Moderatoren
Richtiges Löschen von Datensätzen
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
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
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21200
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Richtiges Löschen von Datensätzen
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.
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.
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!!
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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
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
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9373
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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:
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).
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:
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.Im Netz ist es langsam ...
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).
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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)Tom hat geschrieben:Zunächst einmal erzeugt DbPack() tatsächlich eine temporäre Kopie der Tabelle, vermutlich auf einem ähnlichen Prozess wie "COPY TO ... FOR !Deleted()" basierend.
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
Gruß
Hubert
Hubert
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2470
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
Hubert,
was meinst Du damit ?
was meinst Du damit ?
Es gibt aber tatsächlich Anwendungen die immer alle Dateien offen haben und wer möchte schon Wochenenddienst schieben
Gruß
Klaus
Klaus
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9373
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.Es gibt aber tatsächlich Anwendungen die immer alle Dateien offen haben und wer möchte schon Wochenenddienst schieben
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.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.
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.
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9373
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.
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.
Herzlich,
Tom
Tom
- Manfred
- Foren-Administrator
- Beiträge: 21200
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Richtiges Löschen von Datensätzen
Hi Tom,Tom hat geschrieben: 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.
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.
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: 9373
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.
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.
Herzlich,
Tom
Tom
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.
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.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
Du GlüclklicherManfred hat geschrieben: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.
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
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.
Ich rate davon ab.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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.
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.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Richtiges Löschen von Datensätzen
das gilt IHMO auch für PACKTMP=<Verzeichnis>
Im TMP Verzeichnis werden temporäre Dateien angelegt, z.B. wenn INDEX ON oder DbSort() ausgeführt wird.
gruss by OHR
Jimmy
Jimmy
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1931
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
Hallo Jan
was ist Typ S bei Foxcdx ? was kann ich damit erreichen ?
was ist Typ S bei Foxcdx ? was kann ich damit erreichen ?
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1931
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Richtiges Löschen von Datensätzen
Hi Jan
danke für den Hinweis. Vielleicht kann ich es mal gebrauchen.
danke für den Hinweis. Vielleicht kann ich es mal gebrauchen.