Migration problem going from TDACDSDataTable to TDAMemDataTable (part 2)

hi Evgeny,

stumbled on a new issue:
we have a digital metaphors reportbuilder report that prints groupby totals based on a DAdataset

in code i sort the Dadataset using the .Sort method (3 fields)
this worked fine with TDaCDS
but with TDaMEM it seems that the sort isn’t taken into account by RB
the TDaMEM dataset is even unsorted after printing the report

so something gets screwed up…
any idea why the Sort does not work when printing?

can you give a simple example how to you sort MemDatatable, pls ?

FInventarisDATable.Details.Sort ([fld_InventarisDetailivd_ivt_Primkey,
                                      lSortField,
                                      fld_InventarisDetailivd_Productnaam],
                                     [sdAscending, sdAscending, sdAscending]);

FInventarisDATable is the Master
FInventarisDATable.Details is the details table (exposed as property on the master table class)
lSortField is a dynamic field…

OT, this is the largest topic on this forum? I believe it is. :grinning:

And now was hijacked with another topic! :woozy_face:

1 Like

they are all related to the migration path so …

1 Like

as for me, the sort method works correctly and I can’t reproduce any failure with it

24288.zip (1.8 KB)

what do you mean under dynamic field?

it’s a field name that is determined at runtime based on the wanted sort order

don’t get me wrong: the .sort does work (if i hook it to a grid)
but when the report prints, the sort order is gone and the sql order is back in place… (which is the productname btw)
and that was not the case with TdaCDS…

so somehow RB kinda cancels the sort… i guess…

Can you create a simple testcase that reproduces this case, pls?
you can drop email to support@ for keeping privacy


Note: if you are using CloneSource feature, you need to perform sort for each clone …

i’ll have a look for the testcase

trying to alter your demo:
i’m adding recs in the loop but i want them to be in ‘name’ order (new field)
but it seems that adding them from A to Z displays them in Z to A order, that is, the last field appears on top
when the memtable is unsorted
why is that?

so the inserted recs display in the opposite order in which they were created (latest recID on top of the grid)

I’ve used table.AddRecord that calls

  Insert;
...
  Post;

if you used table.Append, it will be in correct order.

ok

ok after testing i came to the following conclusion:

  • tDAMEM
    i’ve set up a MD releation
    i add 3 recs in the master, 1,2,3; last one (3) stays the active one
    i add multiple details but all for master 1
    i hook up the grids, master 3 appears selected but all details of master 1 are shown
    so adding details in a MD relation for a non current master does not filter out the details unless you move the master pointer
  • sorting works but as soon as the master changes the sort is gone
    *tDaCDS
    same setup, but here the grids are correct, master 3 is selected but no records show
    after moving to the correct master the records do show
  • sorting works even after changing the master rec

now the fact that the sorting stays active in master rec movements result in a correct result in the report
why the master in our app would change i haven’t found yet but this is the only explanation as why the report can’t do a group by since the sort order gets messed up

i can forward the demo as is but it’s more to see the grid behaviour as i haven’t reproduced the report master record move in the report yet…

uDAMemDataset.pas:

      mdnInsert:
         begin
           if FilterMasterRecord_OneRecord(Buf) then begin
..
           end
//add this block
           else begin
             {$IFDEF MEMDATASET_APPLY_MASTER_FILTER_AFTER_EDITING}
             RecordNotification(buf, mdnDelete);
             Exit;
             {$ENDIF}
           end;
//end
         end;
      mdnModify:

this should hide added records

i’m not on the latest release
is this a fixed issue?

it was added at the end of November 2020


then use it w/o {$IFDEF ...}

hmm didn’t i stumbled on this already - i’ll check my temp patches

it was present in mdnModify mode. Now I’ve added it for mdnInsert

exactly that was my patch:
mdnModify:
if IsActiveFilter and not FilterSingleRow(Buf, True) then begin
i := f_DefaultIndexRecord.DataList.Remove(buf);
if (i <> -1) and (i = FRecordPos) and (FRecordPos >= RecordCount) then Dec(FRecordPos);
end
else if FilterMasterRecord_OneRecord(Buf) then begin
if f_DefaultIndexRecord.DataList.IndexOf(buf) = -1 then intInsertRecord(Buf);
FNeedResort:= True;
end
//ma BEGIN patch needed for changing master key in child table
else begin
RecordNotification(buf, mdnDelete);
Exit;
//ma END patch needed for changing master key in child table
end;