hi!
ich sag ja: nicht gerade elegant
war nur als „kürzerer“ vorschlag gedacht (mit änderungen in einem cursor hab ich äußerst schlechte erfahrungen
(auf einer produktiv-db *argh*)
und vor Allem nicht
performant, da innerhalb der Loop u.U. n mal ein
Full-Table-Scann durchgeführt wird.
sowas nennt man dann „einen patch einspielen“, oder? 
Also nichts um das Ding 20 x am Tag laufen zu lassen. Aber ich
vermute das jemand der doppelte DS in einer Tabelle hat daraus
lernt und sich nach dem delete überlegt wie er das in Zukunft
vermeiden kann.
ein typischer fall, in dem ein analyst ein „dieser fall wird nicht auftreten“ vorausschickt und das er-modell und db-design von den entwicklern im nachhinein umgekrempelt wird … (nur einmal möchte ich in einem projekt das „exact fetch returns more than one row“ NICHT sehen - es ist doch nicht so schwer, zumindest ein paar unique-keys zu definieren)
Solche Sachen bieten sich aus meiner Sicht an, wenn man
zusätzlich noch weitere Infos in einen Logfile/Logtable
schreiben möchte.
Viele Grüße
Ratloser
grüße,
tomh