Transaction auf Änderungen überprüfen

[Morphie]

Zuerst mal: Ich habe eine Connection, eine Transaction, diverse Queries, DataSources, DBGrids und DBEdits.

Ich möchte dem Anwender jetzt die Möglichkeit geben, Änderungen an allen Daten durchführen zu können.
Die Änderungen sollen aber noch nicht sofort in die Datenbank geschrieben werden, sondern erst per Knopfdruck.

Beim Speichern führe ich einfach ein Commit der Transaction aus und alle Daten sind gespeichert.
Führe ich das Commit nicht aus (z.B. weil ich das Fenster einfach schließe) sind die Änderungen verworfen (automatisches Rollback).

Jetzt ist es so, dass der Speichern-Button (der mit einer TAction verknüpft ist), immer aktiv ist. Er ist also auch aktiv, wenn überhaupt keine Änderung durchgeführt wurde.

Gibt es einen sauberen Weg, den Button / die Action nur zu aktivieren, wenn sich auch wirklich etwas an den Daten geändert hat (Update / Insert)? Also quasi eine "Ist die Transaction dirty?"-Abfrage
Oder muss ich jedes DataSet überwachen und ein Boolean-Feld "FDataModified" einführen?

[mjustin]

Wenn möglich verwende ich TClientDataSet, und habe damit eine Property

http://docwiki.embarcadero.com/Libra...et.ChangeCount

In der ActionManager Eventbehandlung (OnUpdate) werden dann alle aktiven ClientDataSets geprüft, ob eines mit ChangeCount > 0 dabei ist.

[DeddyH]

Ich habe gerade meine IBDAC-Hilfe nicht parat, aber vielleicht hilft dieser Thread weiter?

[Lemmy]

Hi,

hast Du schon mal die Ereignisse von IBCTransaction angeschaut?

Bei mir gibts da OnStart, OnCommit und OnRollback - das sollte doch ausreichen um deinen Button zu steuern?

Grüße

[Morphie]

werde ich mir morgen mal genauer ansehen... Danke =)

[Morphie]

Zitat von DeddyH:

Ich habe gerade meine IBDAC-Hilfe nicht parat, aber vielleicht hilft dieser Thread weiter?

Also die Eigenschaft Active steht bei mir immer auf true. Ist ja auch klar, da die Transaktion ja bereits aktiviert wird, wenn ich mir die Daten aus der Datenbank hole...
Ich brauche aber irgendwie ein Ereignis, um zu ermitteln, ob es Änderungen gibt.

Zitat von Lemmy:

Hi,

hast Du schon mal die Ereignisse von IBCTransaction angeschaut?

Bei mir gibts da OnStart, OnCommit und OnRollback - das sollte doch ausreichen um deinen Button zu steuern?

Grüße

Hier gilt das gleiche... OnStart wird ausgeführt, sobald ich mir die Daten hole... Das mache ich im OnCreate der Form. Somit ist der Speichern-Button immer aktiv.

[haentschman]

Guten Morgen...

unabhängig von der Frage eine Bemerkung. Transaktionen sollten so kurz wie möglich offen gehalten werden. Schon gar nicht über die Programmlaufzeit. Denkanstoß: Was passiert wenn eine Transaktion offen ist und die Putze den Stecker vom Computer rauszieht ? Der bessere Weg ist die Daten z.B. in Objekten / Listen zu halten, ein Event bei Änderungen auslösen, das Objekt in eine "Changed List" eintragen und ggf. ein Changed Flag setzen. Diese Daten können dann in einem schnellen Rutsch aktualisiert werden.

[Morphie]

Wenn ich dich richtig verstehe, würdest du von Datensensitiven Controls abraten, bzw. eine weitere Zwischenschicht zwischen Datenzugriff und Präsentation ziehen?
Dann wären wir wieder beim leidigen Thema "Wie binde ich dann eine Liste von Objekten einfach an meine GUI?"
Und nimmt mir Delphi da die Arbeit fürs ChangeTracking ab?

Soweit mir bekannt, ist das in Delphi nur mit viel Programmieraufwand möglich.
Der RAD-Ansatz geht meiner Meinung nach dabei flöten... Ich lasse mich aber gern eines besseren belehren

[p80286]

Zitat von Morphie:

Wenn ich dich richtig verstehe, würdest du von Datensensitiven Controls abraten, bzw. eine weitere Zwischenschicht zwischen Datenzugriff und Präsentation ziehen?

Jo

Zitat von Morphie:

Dann wären wir wieder beim leidigen Thema "Wie binde ich dann eine Liste von Objekten einfach an meine GUI?"
Und nimmt mir Delphi da die Arbeit fürs ChangeTracking ab?

Soweit mir bekannt, ist das in Delphi nur mit viel Programmieraufwand möglich.
Der RAD-Ansatz geht meiner Meinung nach dabei flöten... Ich lasse mich aber gern eines besseren belehren

Mal abgesehen von den vielen Schlagworten die Du nutzt, ich hab da kein Problem, meine Daten in ein paar Records und Listen unter zu bringen. Einmal ordentlich definiert, Ruhe für die nächste Zeit.
Eine Gui ist wesentlich aufwendiger.

Gruß
K-H

[haentschman]

Kurz nur meine, und nur meine , Meinung...

Ich habe früher auch mit datensensitiven Controls gearbeitet. Es war manchmal ein Krampf es vernünftig zum Laufen zu kriegen je komplexer das ganze wurde. Seit ich die Datensätze als Objekte abbilde (über eine Zwischenschicht) ist es viel einfacher und übersichtlicher. Man kann z.B. in den Objekten Informationen als Properties ablegen welche nicht in der Datenbank stehen.

Einfaches Beispiel:

Früher:
- Query -> DataSource -> DBGrid.
- Änderungen (Edit) an der Query
- zurückschreiben über ApplyUpdates
-> ging nicht bei komplexen Queries die Daten aus verschiedenen Tabellen beinhalten.
-> Transaktionssteuerung teilweise kompliziert bis unmöglich

Heute:
- Query -> DS werden zu Objekten gewandelt -> in generischer Objektlist abgelegt (Zwischenschicht)
- Listview z.B. -> Objekt Properties zur Visualisierung -> Objekt in Data abgelegt (Pointer auf das Objekt in Liste)
- über Data des Listvieweintrages kann man direkt auf das Objekt zugreifen, Properties ändern etc.
- jedes Objekt weiß dann selbst ob es geändert wurde (Property Changed z.B.)
- beim Speichern erledigt die "Zwischenschicht" den Datenbankzugriff und generiert die SQL Statements, Transaktionen etc.
--> Vorteil: Der Listview ist es egal wo die Daten herkommen... aus Datenbank, XML, CSV etc. und ist damit leicht austauschbar (Optik vieleicht)

Der RAD Ansatz geht, wie du schon sagtest, flöten... Ich habe aber das Gefühl, daß man seine Anwendung besser im Griff hat wenn man mit Objekten arbeitet. Der Aufwand ist natürlich höher. Rechnet sich aber je komplexer das wird.