TADOQuery Daten manuell updaten

[menten]

Hallo zusammen,

ich muss hier mal ein Frage loswerden und hoffe das sie nicht ganz daneben ist.

Es geht um die standardmäßig mit Delphi gelieferten ADO-Komponenten. Wenn ich damit z.B. mit TADOQuery in einer SQL-Datenbank eine Sicht abfrage, kann ich Änderungen natürlich nicht speichern. Zu BDE-Zeiten gab es dafür ein "UpdateObject" wo man dann individuelle Update bzw. Insert Statements verwenden konnte. Das gibt es bei den ADO-Konponenten nicht. Ich habe schon mehrfach nach einer Lösung dazu gesucht, lande aber immer bei der Verwendung von Fremdkomponenten. Im Moment benutze ich Adonis von WINSOFT. Die kann man aber nicht parallel zu den normalen ADO-Komponenten betreiben was immer wieder zu Problemen führt. Auch weil Delphi (XE7, 10.2) offensichtlich Schwierigkeiten hat, die Einstellungen zu verwalten. Ständig werden die Standard ADO-Komponenten geladen obwohl sie eigentlich deaktiviert sind.

Gibt es mit den Standard ADO-Komponenten eine Möglichkeit, das Speichern abzufangen und manuell durchzuführen?

Danke und Gruß
Stefan Menten

[jobo]

Also erstmal:
Man kann Views updaten. Das hat weniger mit der (ADO)Komponente zu tun, als mit dem Aufbau des Views.
Der View muss z.B. auf jeden Fall das PK Feld beinhalten. Wie weit das geht ist von den Fähigkeiten des DB Servers abhängig.
Notfalls (wenn View direkt Update gewünscht) das Verfahren bzw. die Update Fähigkeit des Views zu Fuß in der SQL Konsole ausprobieren.

Ansonsten kannst Du ohne weiteres mit einer zusätzlichen Adoquery das Update selber zusammenbauen und auslösen. Aufhänger wäre vermutlich das BeforePost des darstellenenden Queries.

[p80286]

Grundsätzlich halte ich sehr wenig von solch "intelligenten" Komponenten, da das "one fits all" im allgemeinen dann versagt wenn man es nicht erwartet, bzw. wenn man es am wenigsten gebrauchen kann. darum erstelle ich die notwendigen Insert/Updatestatements immer selber. Das ist zwar etwas aufwendiger, aber Du hast dann alles unter Kontrolle.

Gruß
K-H

[jobo]

Ja, da hast Du nicht Unrecht.
Aber einen View in eine ADOQuery zu kippen statt einer Table ist ja erstmal legitim und eben machbar.
Ist der View dann nicht geeignet für ein Update/Insert, kann man immer noch nachlegen und den "Zusatzaufwand" betreiben.
Entweder durch manuell erstelle Insert/Update Queries nebenher wie Du vorgeschlagen hast oder durch etwas "feilen" am Aufbau des Views.
Genauer: Auch das Update einer berechneten Spalte im aktualisierbaren View wird natürlich fehlschlagen, da kann der Viewaufbau dann nichts dafür. Hier reicht es ggF schon, die berechnete Spalte readonly zu setzen.

[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

[p80286]

Zitat:

Zitat von menten (Beitrag 1376703)

Es geht um die standardmäßig mit Delphi gelieferten ADO-Komponenten. Wenn ich damit z.B. mit TADOQuery in einer SQL-Datenbank eine Sicht abfrage, kann ich Änderungen natürlich nicht speichern.......

Gibt es mit den Standard ADO-Komponenten eine Möglichkeit, das Speichern abzufangen und manuell durchzuführen?

Wie Du schon richtig festgestellt hast, gibt es bei der ADO-Query keine "automatische" Specherung. Du mußt diese immer von Hand als Insert oder Update-Statement absetzen. Es ist somit auch nicht nötig ein Event "abzufangen".

Die Adonis-Komponenten können natürlich andere Eigenschaften haben. Aber das wäre dann eine andere Baustelle.

Gruß
K-H

[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...:P
Ich wollte grad noch einen Vorschlag machen...

Zitat:

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

...genau. 8-) 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. :thumb:

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. :wink:

Wenn du möchtest kann ich ein Minimalbeispiel machen.

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1377370)

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. :thumb:

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

Gruß
K-H

[haentschman]

Zitat:

hatten wir da nicht vor kurzem was zu

...das hatte ich einem Beitrag auch als Vorschlag. Ich mache mal ein Beispiel. Die Frage ist, wo hänge ich das an. :gruebel:

[nahpets]

Du sprichst das Thema häufiger an, mach doch "einfach" mal ein Tutorial dazu und stelle uns das unter Tutorials und Kurse zur Verfügung.

Es dürfte sicherlich viele interessieren, wie Du diese Aufgabe gelöst hast.

[haentschman]

Euer Wunsch ist mir Befehl... :P
Dann mache ich mich mal dran.

[p80286]

Danke!

K-H

[Jumpy]

Zitat:

Zitat von haentschman (Beitrag 1377370)

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. :thumb:

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

[haentschman]

Zitat:

Das klingt jetzt ein bißchen nach einem eigenen ORM-Framework?

...nicht so spannend wie es aussieht. Im Prinzip ist es ein Mini-ORM genau nach meinen projektspezifischen Bedürfnissen ohne Overhead. (Stichwort: YAGNI – you ain’t gonna need it)

[haentschman]

Moin...:P

Das "Datenbank mit Objekten Tutorial" ist fertig. :thumb: Ich habe, für den Notfall, 3 Flaschen Baldrian auf dem Schreibtisch stehen... :stupid: Es kann nicht so schlimm werden. :zwinker:
http://www.delphipraxis.net/193418-%...datenbank.html