Editing master table after disablecontrols incorrectly marks the details as fetched

Data Abstract
1

I have master-detail linked tables
For some editing in the master on all records I call disablecontrols and then update the master records.
For each record I edit however the child is incorrectly marked as fetched.

After debugging I notice that my post calls InternalBeforePost … ReplaceMasterKey … AddMasterKey

The key of my master record did not change, however I noticed that ReplaceMasterKey compares theTDAMasterKeyID pointers instead of the content ( if aOldKey = aNewKey then Exit;)
Is this a bug?
If so, can it be fixed?
If not, am I doing something wrong? How can we edit master records while controls (childs) are disabled?
FYI: I am using RO v9.3.105.1351
TIA

2

can you create a simple testcase that reproduced this case, pls?
you can attach it here or send directly to support@

3

It would take me some time to create a test application.
I was hoping the information I gave sufficed.
I would expect that in TDADataTable.ReplaceMasterKey
the line
if aOldKey = aNewKey then Exit;
would need to become something like
if TDAMasterKeyList_Compare(aOldKey,aNewKey)=0 then Exit;

Please let me know if the sample is absolutely necessary
-A busy programmer-

4

Thanks, logged as bugs://80190

5

bugs://80190 got closed with status fixed.

6

updated fix:

procedure TDADataTable.InternalBeforePost_DoEdit;
...
    if dt.Active and (dt.fOldMasterKey <> nil) 
    and (dt.fFetchedMasters.IndexOf(dt.fOldMasterKey)<>-1)  //this line was added
    then
7

Thanks for the fast support.

Note: I am not sure if something else needs to be done in case the key of a master record changes.
Is the child also inaccurately considered as fetched in that case?

8

bugs://80190 got reopened.

9

I’ve updated fix a few posts above.
In case master key is changed, you need to manually update details table and replace old master key with new one in that records.

10

bugs://80190 got closed with status fixed.