TFDTable edit fails with Firebird 2.5.7 not 2.5.3

Clash Royale CLAN TAG#URR8PPPTFDTable edit fails with Firebird 2.5.7 not 2.5.3
This code:
FDConnection.Open; // Design time TFDConnection; default settings
TabelGrid.Close; // TDFTable connected to TFDConnection; default settings
TabelGrid.TableName := 'TT_ACT';
TabelGrid.Open;
TabelGrid.Edit;
TabelGrid.FieldByName('TT_NAME').AsString := TabelGrid.FieldByName('TT_NAME').AsString + '*';
TabelGrid.Post;
fails with
[FireDAC][Phys][IB]-312 Exact update affected [0] rows, while [1] was requested
when Firebird 2.5.7 is installed, not when Firebird 2.5.3 is installed.
Call stack:

Conditions:
TFDConnection
sysdba
TFDPhysIBDriverLink
TFDPhysFBDriverLink
The table has 3 indices:
TT_I0_ACT TT_ACT_ID Primary
TT_I1_ACT TT_PARENT_ID
TT_I2_ACT TT_FROMDATE
I've fumbled with settings, especially changing the default UpdateOptions.UpdateModes from UpWhereKeyOnly to UpWhereChanged or UpWhereAll, but no results so far.
UpdateOptions.UpdateMode
UpWhereKeyOnly
UpWhereChanged
UpWhereAll
What can be going on; what else can I investigate?
We distribute Firebird 2.5.3 with our app, but I'm afraid it will fail when clients already have a later version (as we found out when one of our developers upgraded FB).
Additional research:
The query that I see in TFDPhysCommandAsyncExecute.Execute (FireDAC.Phys.pas) for both versions is (with the default UpWhereKey update mode):
TFDPhysCommandAsyncExecute.Execute
FireDAC.Phys.pas
UpWhereKey
UPDATE TT_ACT SET TT_NAME = :NEW_TT_NAME WHERE RDB$DB_KEY = :OLD_DB_KEY
(actually, all FCommand properties show identical in the inspector).
FCommand
I've looked through the Firebird 2.5.x. release notes and saw only one in 2.5.6 that is somewhat related:
The number of affected rows was reported incorrectly for an update against a view created WITH CHECK OPTION
I'm not sure this applies because it's about views. Setting UpdateOptions.CountUpdatedOptions to false makes no difference.
UpdateOptions.CountUpdatedOptions
There's nothing in the 2.5.8 fixes list that indicates that a relevant bug was introduced in versions 2.5.4-2.5.7.
I have traced the FireDAC code to the point where execution differs in 2.5.3 and 2.5.7 but that ends with an interface method that I cannot trace:
TFDTable.InternalPost
TFDDataSet.InternalPost
TFDAdaptedDataSet.DoProcessUpdateRequest(arUpdate
TFDCustomTableAdapter.Update
TFDCustomTableAdapter.UpdateAdapterCmds(const ACmds: array of TFDActionRequest);
ACmds contains (arUpdate, arFetchRow)
back to TFDCustomTableAdapter.Update
TFDDAptTableAdapter.Update
TFDDAptTableAdapter.ProcessUpdate
In the 'build command if required' part
oCmd.SQLText := 'UPDATE TT_ACT'#$A'SET TT_NAME = ?'#$A'WHERE RDB$DB_KEY = ?'
ProcessRequest
in TFDDAptTableAdapter.ProcessRequest
SetParamsFromRow(ACommand.Params, ARow);
AParams.Count=2: NEW_TT_NAME and OLD_DB_KEY. OLD_DB_KEY value is 0 in both cases
then
ACommand.Execute;
TFDPhysCommand.Execute
ExecuteTask
TFDPhysCommand.ExecuteTask
FExecutor.Run
TFDStanAsyncExecutor.Run;
TFDStanAsyncExecutor.ExecuteOperation
FOperationIntf.Execute;
TFDPhysCommandAsyncExecute.Execute
TFDPhysCommand.ExecuteBase
FExecutor.Launched; -> Interface, cannot trace
Process_SingleRow
Process_HandleSystemFailure
InternalExecute -> Interface, cannot trace
This last call returns with var parameter ACount to 1 for 2.5.3, and 0 for 2.5.7
The GetRowCounts function returns
FRowsUpdated,FRowsDeleted,FRowsSelected,FRowsInserted: 1 0 1 0 in 2.5.3
FRowsUpdated,FRowsDeleted,FRowsSelected,FRowsInserted: 0 0 0 0 in 2.5.7
is there a way you can explicitly key the primary key columns into the table component? it seems the
UPDATE message sent to server (you did not show it) had problematic WHERE part which kept visible those very "0 rows" /// BTW, 2.5.8 is the last in the line, not 2.5.7– Arioch 'The
Jul 4 at 9:02
UPDATE
WHERE
if you do commit the transaction, disconnect and reconnect, would the row in the database be really changed or not? (also, is it a one-singleton-row table that you do not care which row you do change?)
– Arioch 'The
Jul 4 at 10:44
If the data is not persisted, you may want to explicitly put primary key fields into
UpdateOptions.KeyFields and switch the dataset to using those instead of RDB$DBKEY - docs.embarcadero.com/products/rad_studio/firedac/…– Arioch 'The
Jul 4 at 10:47
UpdateOptions.KeyFields
RDB$DBKEY
Inspect what's happening inside the
TIBStatement.GetRowCounts method.– Victoria
Jul 4 at 11:21
TIBStatement.GetRowCounts
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
Did the CountUpdatedRecords option change between the releases?
– nil
Jul 4 at 9:00