Mein Vorschlag geht nur erstmal dahin, dass Löschen zu verbieten.
Das man dann ggfls. auch Logiken für Sonderfälle benötigt, sollte absolut klar sein.
Es ist nur erstmal ein Workaround, um das "unmotivierte Verschwinden von Mastersätzen" zu verhindern.
Und natürlich bekommen (erstmal) Master und Detail jeweils ihren entsprechenden Trigger.
Löschen darf (laut Eingangspost) nur der Admin.
Der Trigger braucht also letztlich irgend einen Hinweis darauf, wie er den Admin erkennen kann.
Nach dem bisherigen Wissensstand scheint mir eine datenbankseitige Abhängigkeit zu fehlen, die sicherstellt, dass kein Master gelöscht werden kann, wenn es noch Details gibt.
Ob Details gelöscht werden dürfen, kann ich dem Thread momentan nicht entnehmen.
Zitat von
haentschman:
Ich bin schon der Meinung, ein Log schreiben zu müssen. (AfterDelete)
Warum nach dem Auftreten des Fehlers was ins Log schreiben?
Warum nicht im BeforeDelete 'ne
Exception werfen, per MessageDLG "Willst Du wirklich?" fragen oder einfach per Cancel ... das Löschen verhindern.
Wenn ich etwas nicht will, dann versuche ich es vorher zu verhindern und nicht nachher irgendwie zu reparieren.
OK: Im BeforeDelete etwas für den Workflow sinnvolles machen und ggfls. das Löschen verhindern. Im AfterDelete protokollieren (falls denn doch ausnahmsweise gelöscht werden durfte).
Und der Smiley hinter meinem
Zitat:
Und kann heute bzw. morgen, am letzten Tag, noch erstellt werden
sollte darauf hinweisen, dass das nicht wirklich ernsthaft heute oder morgen umzusetzen ist. Also keinesfalls ein
Zitat von
himitsu:
Und jupp ... schnell schnell, dat schaffst schon noch. (das Wasserfall-Model ... nach mir die Sintflut)