Warnhinweis falls ein User mehr als 100 Datensätze löscht

Hi zusammen,

ich wollte gerade eine Warnung einbauen für den Fall, dass ein User mehr als 100 (einrichtbar) Datensätze löscht. Dazu habe ich mich an Codeunit 1 - OnAfterOnDatabaseDelete gehängt. Ich hatte da allerdings den Denkfehler, dass ich dann RecRef.Count abfragen könnte - allerdings ist es ja so, dass wenn ich Datensätze auswähle auf einer Page und diese dann lösche, kein Filter vorhanden ist, sondern OnAfterOnDatabaseDelete einfach für jeden Record einzeln durchlaufen wird.

Meine nächste Idee war jetzt, eine Variable hochzuzählen und wenn ich bei 101 angelangt bin, ein Confirm erscheinen zu lassen, damit der User das abbrechen kann, wenn es nicht gewollt war (wir hatten mehrfach das Problem, dass Benutzer versehentlich auf einer Page den Filter gelöst und alles markiert und gelöscht haben). Allerdings kann ich denke ich über den Subscriber keine Variable so "global machen", dass das funktioniert. Eine Tabelle nur dafür fühlt sich over the top, Performance-ungünstig und Sperren-lastig an.

Hat jemand evtl. eine Idee?

Hallo,

du kannst das nur pro spezifischer Tabelle machen, da es ja auch sein kann, das auch in abhängen Tabellen Datensätze gelöscht werden. (Ich denke es sollte kein Problem sein, einen Auftrag mit mehr als 100 Zeilen beim Buchen zu löschen.)

Eine andere Möglichkeit wäre es im OnDelete- Trigger der Page ( nicht der Table) eine Abfrage einzubauen, die ab einer bestimmten Anzahl zu löschender Datensätze eine Bestätigung via Confirm anfordert.

Gruß Fiddi

Eigentlich möchte ich es nicht pro spezfischer Tabelle machen. Aber habe ich da nicht das gleiche Problem, dass ich die Anzahl gar nicht abfragen kann?

Es wäre nicht schlimm, wenn die Meldung auch für abhängige Tabellen käme; so oft haben wir keine Aufträge etc. mit mehr als 100 Zeilen. 100 war auch nur ein Beispiel; in den konkreten "Ups"-Fällen wurden Zehntausende Datensätze gelöscht. Wenn da ab und zu eine Meldung vor dem Löschen bei normalen, gewollten Vorgängen bestätigt würde wäre das auch kein Problem.

Wenn ich die Abfrage nur in Pages x, y und z einbaue, habe ich für die 200 anderen Pages, auf denen sowas passieren kann, ja nicht abgefangen.

Hallo,

Wenn ich die Abfrage nur in Pages x, y und z einbaue, habe ich für die 200 anderen Pages, auf denen sowas passieren kann, ja nicht abgefangen.

Sind das wirklich so viele? Das einzige wo mir das im Moment sinnvoll erscheint wären Buchblätter und da kannst du problemlos eine 0 von deinen 200 streichen.

Gruß Fiddi

ich find's blödsinnig, aber egal....
versuch's über eine SingleInstance Codeunit - sprich deinen Counter dort hochzählen...

Hallo,

und wann setzt du den Zähler zurück?

Gruß Fiddi

die SI merkt sich, aus welcher Table gelöscht wurde - wird eine andere Table angesprochen, dann zurücksetzen....aber und das wissen wir, ist das defintiv nicht das Ende vom Lied....da muss ein "bisschen" mehr drüber nachgedacht werden.

Ich sehe das ähnlich wie sweikelt.

Die Frage ist, welche Tabelle mit 10000 Datensätzen lässt sich einfach löschen?
Wenn man das Design von NAV berücksichtigt, gibt es meines Erachtens kein generelles Problem, außer bei Buchblättern.

Man könnte auch in den Pages dafür sorgen, dass der Filter nicht lösbar ist.

Ihr glaubt nicht, auf was für Ideen die End-Anwender kommen, wenn sie versuchen, sich die Arbeit einfacher zu machen.

Wir hatten selber mal das Problem, dass bei uns ständig alle Belegzeilentexte (Add-On) zu allen Verkaufsbelegzeilen verschwanden.
Dann hatten wir den Delete mit dem ChangeLog protokollieren lassen und konnten so den Anwender ausfindig machen, um ihn zu fragen, was er gerade gemacht hat.

Die Antwort war ganz einfach:
"Ich wollte alle Belegzeilentexte aus allen Zeilen des Auftrags löschen, also habe ich auf "Filter löschen" geklickt, alle markiert und gelöscht. Das geht viel schneller als es für jede Zeile einzeln zu machen."

Das Problem: Er hat damit nicht nur den Filter auf die Zeilennr. gelöscht, sondern auch auf Belegart und Belegnr., so dass alles gelöscht wurde.

Die Lösung: Anstatt die Form (es war halt noch unter NAV 5.0) der Belegzeilentexte über das Property RunFormLink zu filtern (den der Anwender aufheben kann), haben wir alle Aufrufe auf C/AL-Code umgestellt und filtern nun die Belegart und Belegnr. in einer anderen FilterGroup, so dass der Anwender den Filter nicht mehr lösen kann. (Den Filter auf die Zeilennr. hatten wir bewusst in der FilterGroup 0 gelassen, damit sie bequem alle Texte zu allen Zeilen löschen können.

Eine Abfrage ab xxx zu löschender Datensätze halte ich für den falschen Ansatz, da es einfach zu viele Szenarien gibt, die man gar nicht sauber identifizieren kann.
In dem einen Szenario wäre vielleicht schon das Löschen von mehr als 10 Datensätzen eine Vollkatastrophe, während in einem anderen Szenario bedenkenlos auch 10.000 Datensätze gelöscht werden dürften.
Wir räumen z. B. regelmäßig alte Einträge in der Tabelle "Change Log Entry" auf. Da kann es sein, dass die Hintergrund-Session eines x-beliebigen Anwenders den Job übernimmt und zufällig zig-tausend alte Einträge zu löschen hat.

Fazit: Nicht erst eingreifen, wenn das Kind schon in den Brunnen fällt (Lösch-Counter und Confirm bzw. Error), sondern schon im Vorfeld verhindern, dass es in den Brunnen fallen kann (Filter in andere FilterGroup schieben bzw. Prüfung im OnDelete-Trigger der jeweiligen Page).
Dazu gibt es leider keine Universal-Methode, sondern man muss jedes "Upps" einzeln untersuchen und passende Lösungen dazu finden.
Wer regelmäßige Datensicherungen in der Hinterhand hat, kann die durch "Upps" verloren gegangenen Daten relativ einfach wiederherstellen.

...Fazit: Nicht erst eingreifen, wenn das Kind schon in den Brunnen fällt ... sondern schon im Vorfeld verhindern, dass es in den Brunnen fallen kann ...

So meinte ich das.