Beim Post wird, entsprechend der geänderten Felder (TField: OldValue<>Value) und dem DataSet-State ein Statement generiert, unter Bezug auf die FieldInfos des Queries.
Bei Insert+Post ein INSERT INTO, bei Edit+Post ein UPDATE und bei Delete natürlich DELETE FROM.
Erstmal wäre es besser, wenn die QueryKomponente das ID/Key/Index-Feld(er) des Datensatz kennen, um ein optimales WHERE genierien zu können.
Und manchmal kann die Code-Generation auch schief laufen.
Schön ist, dass bei Problemen oft garkeine Fehlermeldung kommt und dann garnichts gemacht wird.
Tipp: Hänge einen
SQL-Monitor an die Connection oder schaue im Activity-Log der Datenbank, ob und was für ein
SQL-Statment beim Post abgeschickt wird.
Aus diesem Grund kann man hier bei vielen
DB-Komponenten optional den Tabellennamen angeben, falls er nicht automatisch erkannt wird,
und neben dem
SQL kann man dann auch ein InsertSQL, UpdateSQL und DeleteSQL angeben, wenn eines/alle dieser
SQL nicht automatich aus dem
SQL (SELECT) generiert wird.
TFDQuery.Table
TFDQuery.UpdateObject
TFDQuery.KeyFieldCount
Und nach dem Post wird eventuell noch ein UpdateRecord ausgeführt, wobei dort das WHERE des
Sql (SELECT) ersetzt wird, durch das/die KeyFields,
um die aktuellen Inhalte des grade geposteten Datensatzes zu bekommen, falls z.B. ein Trigger dort anschließend nochmal was geändert hat.
Kommt hier kein Result (RecordCount=0) zurück, dann wird dieser Datensatz natürlich gelöscht, da er scheinbar auf der
DB nicht mehr existiert (durch Trigger gelöscht).