Richtig Speichern

[Furtbichler]

Diese Funktionalität gehört imho nicht in das Formular, sondern in das Modell.

Delphi-Quellcode:

Type
  TModel = Class
    fAModified,
    fBModified : Bool;
    fA : Integer;
    fB : String;
    Procedure SetA(Value : Integer);
    Procedure SetB(Value : String);
  public
    Property A : Integer Read fA Write SetA;
    Property B : String  Read fB Write SetB;
  end

implementation
Procedure Procedure TModel.SetA(Value : Integer);
Begin
  If Value = fA then exit;
  fA := Value;
  fAModified := True;
End;

Procedure Procedure TModel.SetB(Value : String);
Begin
  If Value = fB then exit;
  fB := Value;
  fBModified := True;
End;

Da ich nun weiß, ob und welche Daten sich verändert haben, ist der Rest ein Klacks.

BTW: Mit einem TDataSet wäre das nicht passiert, weil dort alle Felder diese Funktionalität bereits mitbringen.

[kretabiker]

@Furtbichler: Stehe ich jetzt auf nem Schlauch? In deinen Set...-Routinen steht als Vergleich z.B.
If Value <> fA then exit; - das bedeutet doch, das bei GEÄNDERTEN Werten die Procedure verlassen wird, oder? Sollte da nicht eher
If Value = fA then exit; stehen?

Ansonsten teile ich deine Meinung, dass das ins Model gehört - und teile auch grundsätzlich deine Vorgehensweise.

[jobo]

Ich kenne Unidac nicht, aber die TDataset Fähigkeiten hätte ich dort auch vermutet.
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.
Für eine bloße Datensatzänderung eine extra/zusätzliche Transaktion aufzumachen, scheint mir etwas übertrieben.

[Furtbichler]

Zitat von jobo:

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).

[jobo]

Zitat von Furtbichler:

Zitat von jobo:

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".