TFDTable edit fails with Firebird 2.5.7 not 2.5.3

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP


TFDTable 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:



enter image description here



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





Did the CountUpdatedRecords option change between the releases?
– nil
Jul 4 at 9:00





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.

Popular posts from this blog

Arduino Mega cannot recieve any sketches, stk500_recv() programmer is not responding

Visual Studio Code: How to configure includePath for better IntelliSense results

C++ virtual function: Base class function is called instead of derived