TADOQuery Daten manuell updaten

[menten]

Hallo zusammen,

erst mal danke für die Antworten. Ich scheine aber mit meiner Frage nicht richtig verstanden worden zu sein. Natürlich kann ich auch eine View so aufbauen, dass man sie updaten kann. Aber spätestens wenn die Sicht aus mehreren Tabellen besteht oder eine Stored Procedure die Daten liefert, ist das ja vorbei. Man könnte natürlich auch mit Triggern arbeiten, das ist aber sehr aufwändig.

Mit geht es um das Ergeignis, welches ich abfragen kann, um das Speichern selbst übernehmen zu können. BeforePost fällt aus, weil man den Vorgang nicht kontrollieren kann. Man könnte den nur mit "Abort" abbrechen oder mit einer Exception unterbrechen. Ansonsten würde der Vorgang fortgesetzt obwohl wir ihn ja schon abgearbeitet hätten.

Ein wie auch immer geartetes Update-Ereignis würde die Information mitbringen, ob Insert, Update oder Delete ausgeführt werden soll und hätte die Möglichkeit den Vorgang als Applied abzuschließen. So haben das die alten BDE-Komponenten gemacht und so macht es auch ADONIS. Allerdings mit dem Problem, das die nicht parallel zu den Standard-ADO installiert sein können.

Danke und Gruß
Stefan Menten

[nahpets]

BDE und ADO funktionieren (zumindest bis Delphi 7) problemlos nebeneinander, auch innerhalb eines Programmes.

Ob's sinnvoll ist, steht auf 'nem anderen Blatt.

Wäre eventuell das Ereignis OnWillChangeRecord der TADOQuery das von Dir gesuchte Ereignis?

http://www.delphigroups.info/2/3/304406.html
http://docwiki.embarcadero.com/Libra...llChangeRecord

[menten]

Hallo nahpets,

BDE hatte ich nur als Beispiel für die Routine genannt, wollte ich nicht wieder mit anfangen.

Aber OnWillChangeRecord könnte funktionieren, muss ich mal ausprobieren. Schon mal so gearbeitet?

Gruß
Stefan

[nahpets]

Nein, noch nicht probiert, aber die Beschreibung klingt so, als könnte man sich da einklinken, die Änderungen machen und dann das von der TADOQuery vorgesehene Speichern abbrechen.

Probleme dürfte man dann (eigentlich?) nur mit datensensitiven Komponenten bekommen, da die von den Änderungen nichts erfahren.

Mit 'nem TADOQuery.Refresh dürfte das Problem aber auch zu lösen sein, sofern man überhaupt datensensitiven Komponenten nutzt.

[menten]

Ich hab das jetzt mal ausprobiert.

OnWillChangeRecord und OnRecordChangeComplete wird aufgerufen, bevor das eigentliche Speichern in der Datenbank passiert. In beiden Ereignissen kann man das Speichern erledigen. Aber der Ablauf wird nicht unterbrochen und man bekommt im Anschluss die Fehlermeldung, dass nicht genug Schlüsselinformationen zum Aktualisieren vorhanden sind.

OnWillChangeRecordset und OnRecordsetChangeComplete werden offensichtlich nach dem Speichern in der Datenbank aufgerufen. Da kommt besagte Fehlermeldung nämlich bevor man in den Ereignissen landet.

Sieht für mich so aus, als hätte man hier nur die ursprüngliche ADO Schnittstelle implementiert und alles 1:1 übernommen ohne sich groß Gedanken zu machen.

Wenn man keine datensensitiven Komponenten benutzt, hat man das Problem sicher nicht. Das steht für mich aus Effektivitätsgründen aber nicht zur Debatte.


Gruß
Stefan

[nahpets]

Das OnRecordsetChangeComplete sieht so aus, als würde das ein Ereignis, dass nach dem Speichern aufgerufen wird, dürfte für Deine Aufgabenstellung also eher ausfallen.

Zeig' bitte mal den Quelltext zu Deinem Ereignis OnWillChangeRecord.

Mein erster Versuch würde ungefähr so aussehen:

Delphi-Quellcode:

procedure TForm1.ADOQuery1WillChangeRecord(DataSet: TCustomADODataSet;
  const Reason: TEventReason; const RecordCount: Integer;
  var EventStatus: TEventStatus);
begin
  ... hier die erforderlichen Änderungen "quer durch die Datenbank" machen

  EventStatus := esCancel; // Bricht hoffentlich das weiter Verarbeiten der Datenänderung ab.
end;

[haentschman]

Moin...
Ich wollte grad noch einen Vorschlag machen...

Zitat:

Wenn man keine datensensitiven Komponenten benutzt, hat man das Problem sicher nicht.

...genau. Die Daten können statt in Datasets in komplexen Objekten liegen. Die Anwendung arbeitet intern ausschließlich mit Objekten. Die Schnittstelle ist ein Datamodule, besser Interface, zur Datenbank. Da werden die Objekte wieder "zerlegt" und in einer Transaktion auf die verschieden Tabellen gespeichert.

Zitat:

Das steht für mich aus Effektivitätsgründen aber nicht zur Debatte.

...könntest du das bitte erklären? Es ist ein Unterschied ob du das in einem Projekt mit 2Mio Zeilen oder du schnell fertig werden mußt.

Wenn du möchtest kann ich ein Minimalbeispiel machen.

[p80286]

Zitat von haentschman:

Die Daten können statt in Datasets in komplexen Objekten liegen. Die Anwendung arbeitet intern ausschließlich mit Objekten. Die Schnittstelle ist ein Datamodule, besser Interface, zur Datenbank. Da werden die Objekte wieder "zerlegt" und in einer Transaktion auf die verschieden Tabellen gespeichert.

Das würde mich jetzt mal interessieren, oder hatten wir da nicht vor kurzem was zu?

Gruß
K-H

[Jumpy]

Zitat von haentschman:

Die Daten können statt in Datasets in komplexen Objekten liegen. Die Anwendung arbeitet intern ausschließlich mit Objekten. Die Schnittstelle ist ein Datamodule, besser Interface, zur Datenbank. Da werden die Objekte wieder "zerlegt" und in einer Transaktion auf die verschieden Tabellen gespeichert.

Das klingt jetzt ein bißchen nach einem eigenen ORM-Framework?
Bin auch mal gespannt wie du das umgesetzt hast.