Andererseits: clientseitige Kontrolle dieser Infos ist ggF. nicht ausreichend.
Wir verwenden ggF. Trigger, die auf Wunsch gleich eine Ändernungshistorie führen (können). So wird wirklich jede Änderung vermerkt.
Es geht eher darum, das UPDATE-Statement sauber hinzubekommen, glaube ich. Ansonsten ist natürlich das RDBMS der richtige Ort, um Änderungen zu protokollieren.
Zitat:
Für eine bloße Datensatzänderung eine extra/zusätzliche Transaktion aufzumachen, scheint mir etwas übertrieben.
Jede Änderungsanweisung ist eine einzelne Transaktion (Stichwort: CRUD, atomar).
Updatestatement: Ja, aber der Teufel ist ein Eichhörnchen. Hat man es geschafft, dass die Anwendung sauber alle Felder berückschtigt natürlich inkl. eines "ChangeDate" bspw, ist man anschließend geneigt, dieses "Changedate" als Maß der Dinge anzusehen und lässt ggF administrative, .. Datenänderungen außer Acht.
CRUD: Eben, ich halte nichts davon in einer Clientanwendung mit eigenen, "handgemachten" Transaktionen rumzuasen, ala "ich sperr mal eben die Tabelle, weil ich hier was auslesen muss und es ganz besonders richtig machen will".