UPDATE zugriff mit ADO -> rückgabe leer! was nun?

[rollstuhlfahrer]

Hallo Wissende,

ich glaub der titel ist etwas umständlich formuliert, was ich meine ist folgendes:

Delphi-Quellcode:

ADOQuery1.Sql.Clear;
ADOQuery1.Sql.Add('UPDATE Tabelle SET feld1 = ' + neu_feld1);
ADOQuery1.Active := true;

Der SQL-Befehl UPDATE hat schon immer keinen Rückgabewert gebracht, aber Delphi meckert jetzt, dass:
"ADOQuery1: CommandText gibt keine Ergebnismenge zurück"
kann ich jetzt diese Errungenschaft, die Delphi gemacht hat jetzt einfach mit einem try-finally-Block wegoptimieren oder gibts da einen eleganteren weg, einen Wert in einer Tabelle zu ändern ohne dass ein Fehler kommt?
Im Notfall bin ich auch für eine erneute Abfrage der Daten ( die ja eigentlich unnötig ist ), aber den Fehler will ich möglichst weg haben.

rollstuhlfahrer

[marabu]

Hi,

bloss nicht stumm schalten diese Meldung: Alle DML Befehle außer SELECT werden mit ExecSQL() verarbeitet!

Grüße vom marabu

[alzaimar]

Ich verwende für einfache Befehle die Execute-Methode der TADOConnection, sonst die TADOCommand-Komponente.

[rollstuhlfahrer]

Danke für die schnelle Antwort,
diese Funktion habe ich bis jetzt stillschweigend übersehen.
Kann ja mal vorkommen, dass man nicht über alles bescheid weis. Dafür gibts Foren

rollstuhlfahrer

[alzaimar]

Och lass mal, passiert öfter. Der Vorteil der TADOCommand-Komponente sind parametrisierbare Kommandos, bei denen Du dir nicht über die konkrete SQL-spezifische Formatierung der Werte (insbesonderen Datumsformat) Gedanken machen musst: Das erledigt ADO/Delphi.

[rollstuhlfahrer]

Ich meld mich nochmal zu Wort,
denn nach einem weitenen Ausbauen vom Quelltext kam ich zum Probelm:
Wie kann ich jetzt herausbekommen, wie viele Zeilen eine SQL-Abfrage gebracht hat.
Nicht jede Abfrage endet quadratisch

rollstuhlfahrer

[alzaimar]

.Recordcount wäre eine Möglichkeit

[marabu]

RecordCount bei SELECT, aber ADOQuery.RowsAffected bei INSERT, UPDATE und DELETE.