well it boils down to a different behaviour of TdaMEM between 1463 and 1491
so i don’t know if the delphi version has any influence on that
I don’t see any significant changes in memDataset between these version.
can you create a simple testcase with Mem datatable that works differently in .1463 and .1491, pls?
i’ve just checked build 1489 in another D10.4 and that one also works correctly (at least as i expect it)
i’ll install 1489 (since 1491 has that bug and i don’t want to patch that unit) in my 10.3.3 and see what gives on monday
we’ll go from there
ok i’ve created a simple demo which shows the difference in active record between CDS and MEM dataset
sending it by email
thx
oh and i stumbled on something else:
why is it possible to pull in the same record over and over again?
(given that there is a primkey)
Hi,
it is possible with LoadFromRemoteSource because it just adds a new record(s) to the end w/o any checking.
With RDA.Fill and aAppendMode = True, it just updates existed record if the same PK is detected in table.
i would surface appendmode in Tdadatatable…
we have therefore an OpenOrAppend(appendmode) method…
no i need to load a record and make it current
.Last should work if you don’t use autosorting
well that would be correct if it’s always just 1 record
i have use for pulling in X recs and then iterating the new ones…
i don’t say that things can’t be done otherwise or even better, i’m just surfacing an incompatibility switching from CDS to MEM and i need to fully understand the impact of me switching camps…
like said i want to get rid of old deprecated stuff… but not if this compromises stability of my release
Hi,
I understand what was a problem and why CDS changes position.
by default, MEM works in superfast mode and adds records received from server w/o Append/Post.
CDS always uses Append/Post that causes changing current position.
workaround:
if you add empty event to bin2 like
procedure Tdm.DataStreamerReadFieldValue(const aField: TDAField; var Value: Variant);
begin
//
end;
bin2 will insert records to MEM via Append/Post and you will get the same behavior like in CDS
ok but that will be slower right?
and that also means that CDS will always positon on the Last record, right? (and not the first of the set that is being pulled in?)
yes, but it isn’t critical for you because you load by one record.
how things works:
CDS.Append;
..
CDS.Fields[x].Value := y;
...
CDS.Post;
in this mode, position in CDS will be last (CDS.Append sets it).
for this mode, activate that event.
in super-fast mode (w/o events), records are inserted directly to internal buffer of MEM w/o Append/Post so position of dataset isn’t changed.
ok it is clear now and i can live with that
it was bad practice to rely on the fact that the loaded rec becomes the active one
still i have to figure out why MEM behaves the same in our application as CDS for release 1491
that said, the demo does not, so there must be something else that probably prevents the use of superfast mode in 1491 and 10.4 test
i’m installing 1491 on my 10.3.3 to see what gives…
superfast mode works only with BIN2 and MEM table.
Bin1 and MEM may work in compatibility mode via Append/Post
btw, .1495 was already published. it solves regression bug in .1491
ah so no more patching dataabstract impl then
my test was with bin2 and MEM…
[dcc32 Warning] o_OffBaseData4Objects.pas(165): W1020 Constructing instance of ‘TDARemoteDataAdapter’ containing abstract method ‘TDABaseDataAdapter.InternalExecuteCommand’
this surfaces after installing 1491… does it ring a bell?
