Richtig Speichern

[Ykcim]

Hallo Zusammen,

ich habe mal ein paar Grundlagenfragen:

Ich habe eine Maske mit mehreren Feldern (Edit, DatePicker, ComboBoxen und Checkboxen), die ich in einer MySQL-Datenbank speichere. Ich habe auch eine Routine geschrieben, von der ich allerdings nicht überzeugt bin. So schreibe ich z.B. immer alle Felder neu, wenn ich eines geändert habe.

1. Wie stellt Ihr fest, welche Felder sich geändert haben und deshalb bei einem Update berücksichtigt werden sollten?

2. Wie setzt Ihr die Sperrung eines Datensatzes um, wenn gerade bearbeitet wird?

3. Ich habe bei den Unidac auch ein Objekt names Transaktion dabei. Allerdings hat anscheinend jede UniQuery schon eine enthalten? Habe noch nie mit Transaktionen gearbeitet...

Noch eine Info. Ich habe eine Klasse für die einzelnen Masken erstellt, sodass die Daten nicht nur in den Feldern, sondern auch in dem Klassenobjekt enthalten sind.

Ich würde mich freuen, wenn ich einige Anregungen von Euch bekommen könnte, wie man richtig speichert.

Vielen Dank
Patrick

[Popov]

Einige Komponenten haben die Eigenschaft Modified, sie zeigen an ob es eine Änderung gab. Allerdings sollte man nach der Speicherung Modified wieder auf False setzen. Allerdings bietet nicht jede Komponente diese Eigenschaft. Einfach nachgucken. TEdit, TMemo und TBitmap haben es, die anderen weiß ich nicht.

[Ykcim]

Okay, vielen Dank für den Hinweis. Ich habe nachgesehen und muss feststellen, das ComboBoxen diese Eigenschaft leider nicht mitbringen. Auch die TAdvComboBoxen von TMS sheinen das nicht zu haben. Wie machst DU das damit?

Gruß
Patrick

[Medium]

Weit mehr Komponenten haben das OnChange() Ereignis. Wenn du zudem noch die Property "Tag" nicht anderweitig nutzt, und sonst auch nichts im OnChange mancher Komponenten machst, könntest du für alle einen gemeinsamen Handler machen, der einfach das Tag des Senders auf 1 setzt, und die Speichern-Routine setzt die wieder auf 0.

Sperrung ist da etwas komplizierter: Im Grunde müsstest du für jede Komponente einen Buffer machen, der die Werte beinhaltet, die die Maske zum letzten Speicherzeitpunkt oder bei der letzten Anzeige in der DB standen. Vor dem Speichern kannst du dann diese mit den dann aktuellen in der DB vergleichen, und ggf. Warnungen und Aktualisierungen machen. Das wäre zumindest eine Möglichkeit, wie man es ganz allgemein und mit allen Komponenten machen könnte, selbst wenn sie selbst keinen Mechanismus dafür vorsehen. Interessant wird dabei dann jedoch, wie man seinen Buffer umsetzt. Da fiele mir jetzt hier spontan noch kein wirklicher Königsweg ein. Zumindest kein schneller, einfacher und eleganter, der nicht schon fast Framework/ORM-Charakter hätte.

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

[mquadrat]

Zitat von Ykcim:

1. Wie stellt Ihr fest, welche Felder sich geändert haben und deshalb bei einem Update berücksichtigt werden sollten?
2. Wie setzt Ihr die Sperrung eines Datensatzes um, wenn gerade bearbeitet wird?
3. Ich habe bei den Unidac auch ein Objekt names Transaktion dabei. Allerdings hat anscheinend jede UniQuery schon eine enthalten? Habe noch nie mit Transaktionen gearbeitet...

1. Wir machen das - wie hier schon gezeigt - mit den Settern. Ergo wir merken uns nur welche Datensätze aktualisiert werden müssen und schreiben dann alle Felder des Datensatzes.
2. Über einen eigenen Dienst, der dann in der Fehlermeldung auch anzeigt, wer was und vor allem warum bearbeitet.
3. Welche Engine verwendest du in MySQL? Bei MYISAM gibt es sowieso keine Transaktionen. Bei InnoDB könntest du welche nutzen, wenn du möchtest.

@Transaktionen-Thema
Wir bündeln durchaus logisch zusammengehörende Operationen in einer Transaktion.