Was ist besser? .EDIT / .POST oder ein UPDATE-Query?

[Sharky]

Hai,

mal ne Frage *g*

Was ist denn vorzuziehen um Datensätze zu ändern?

Delphi-Quellcode:

begin
  Query1.Edit;
  Query1.FieldByName ('spalte').AsString := 'la le lu';
  Query1.FieldByName ('noch_ne_spalte').AsInteger := 0815;
  .
  .
  Query1.Post;
end;

Oder ein UpdateQuery:

Delphi-Quellcode:

begin
  Query1.SQL.Text := 'UPDATE tabelle SET spalte = :spalte, noch_ne_spalte = :noch_ne_spalte WHERE id = :id';
  Query1.ParamsByName ('spalte').AsString := 'la le lu';
  Query1.ParamsByName ('noch_ne_spalte').AsInteger := 'la le lu';
  Query1.ParamsByName ('id').AsInteger := 1;
  Query1.ExecSQL;
end;

Hat das eine gegenüber dem anderen vor/nachteile?

[mschaefer]

Moin Sharky,

Wenn man über Deine musikalischen Integer im 2.Beispiel hinwegsieht
erreichst Du mit beiden Varianten im Datenbankergebnis das Gleiche:

Einen aktualiserten Datensatz in der Tabelle.

Mit dem direkten Update-Befehl sogar schneller und meiner Ansicht auch
übersichtlicher als die Post-Variante.Es ist übrigens die einzige Möglichkeit
bei BDE und Paradox Kombination gewesen Tabellen gemischte edierbare
Datenmengenzu erhalten, da das Standart UpdateSQL Object das nicht unterstützte.

Soweit - sogut. Meines Erachtens dürfte allerdings die aktualiserung der
datensensitiven Elemente (DBGrid) im zweiten Beispiel auf der Strecke bleiben,
da ExecSQL keine Datenmenge zurückliefert. Post führt aber eine Wiederabfrage
der Datenmenge durch

Grüße aus dem frosteligen Hannover

// Martin

[Tyrael Y.]

..ich finde beide Varianten sind wichtig und habe ihren Zweck, da zB. TADOTable Events hat wie BeforePost und AfterPost auf die man im Programmverlauf reagieren kann...

..bei TADOQuery kann man eine WHERE-Klausel ja direkt integrieren, wohingegen man bie TADOTable den Umweg über Locate gehen muss..

..es gibt demnach Vor- und Nachteile für beide Varianten..

..letztendlich kommt es mehr drauf an, was man genau erreichen möchte..

..ich denke auch, daß TADQuery schneller sein müsste..

[Robert_G]

Ich glaube dieses Edit,Post,... macht nur Sinn wenn es schnell (im Sinne von husch-husch hinprogrammiert) gehen muss und man daraufhin auf DBEdits,... ausweichen muss.
Ich persönlich finde die Benutzerfreundlichkeit des DBGrids unzumutbar und verwende deshalb lieber String-/DrawGrids.
Zur Speicherung wird dann ein/mehrere UPDATE-Statement(s) anhand der Änderungen seit der letzten Speicherung zusammengebaut.
Auf die Art bombardiert man die DB nicht mit Updates jedesmal wenn der User die Zeile wechselt und ein String-/DrawGrid ist einfach benutzerfreundlicher.

[Sharky]

Zitat von mschaefer:

...dürfte allerdings die aktualiserung der
datensensitiven Elemente (DBGrid) ...

Jep, das ist "klar" aber darum muss man sich als Programierer auch so immer kümmern.
Da ich es mir abgewöhnt habe mit DB-Sensitiven Objekten (DBEdit, EDLabel, DBGrid usw.) zu arbeiten muss ich für eine aktualisierung immer selber sorgen.

BTW: "La Le Lu" ist doch ein lustiger Fehler für den Compiler? Oder

Spass bei seite:

Was geschiet wenn ich z.B. folgenden Schwachsinn mache.

Delphi-Quellcode:

begin
  Query1.Edit
  ... Delay für 5 Minuten ...;
  Query1.FieldByName ('mein_lied_').AsString := 'La Le Lu';
  .... Dely für noch einmal 5 Minunten...;
  Query1.Post;
end;

Ab wann wird denn der DatenSatz von meiner Datenbank (MS-SQL, MySQL) bearbeitet? Sobald das .EDIT kommt oder erst bei dem .POST?