Upgrading RODA stream read erro

Data Abstract
23

can you create a simple testcase, that reproduces original issue, pls?
we should be able to reproduce it on our side too.
you can send it directly to support@

24

well since the code handles the writing and reading of datmemo (in DA3!) differently i guess it isn’t that hard to simulate…
will need to find some time to do a testcase, we are a very small team with lots of deadlines…
(and i already had to put a lot of time into it to get it working)
the change was made after version 107 iirc

25

actually, code in uDABinAdapter.pas wasn’t touched since 2013 except minor changes unrelated with reading/writing datMemo

26

no the change that causes the problem in uDABinAdapter is the change in uDaDelta.pas
which handles datMemo as a variant array of byte which uDaBinAdapter could not stream…
this change was introduced after build 107 which we were running…

image
image.png1579×510 18.7 KB

27

I see this change.
we had problem when datMemo (i.e. data in AnsiString format) was written as UnicodeString when we used old processing via usual string so we decided to write it the same as datBlob for preventing data loss.
Bin1 wasn’t updated and you caught this issue.

28

yep

29

your changes are correct. no additional changes are needed.

30

bugs://81589 got closed with status fixed.

31

bugs://81598 got closed with status nochangereq.

32

will this fix make it in the next stock release?

33

yep, it was already merged and will be present in the next beta

34

i upgraded to 9.7.115.1441 (since i upgrade to delphi 10.3.2)
now this ‘memo’ problem is here again (DA3)
reading a dataset with a SQLserver field of type TEXT, is misinterpreted
so the resulting strings contain rubbish…

for the moment i’ve changed the uDaBinAdapter.pas unit:

line 1180
function TDABinDataStreamer.DoWriteDatasetData(const Source: IDADataset; var aDataForAppend: TDADataForAppend; aDataIndex: Integer = -1): Integer;
…
line 1308:
// datMemo: fWriter.WriteString(VarToStr(val));
datBlob,datmemo: begin
VariantToWriterAsStr(datBlob, val, fWriter);
end;

since the field is defined in the schema as datMemo it tries to do a VartoStr which does not work
so i guess something is changed again regarding datMemo and legacy DA3

the real question is what is causing the problem now, since my patched version of dabinadapter is exactly the same as the latest stable release one, so somewhere higher it must go wrong?

could you please have a look as to why it behaves wrongly asap?
i don’t want to go back to the 9.5 version…

35

to be clear: i’ve changed line 1038
so datblob and datmemo are treated the same way
furthermore the variant array of byte is getting recognised as:
8209:begin { 8209 is binary array }

37

could this be the cause
{$IFDEF DA_WIDEMEMO_conversion}

38

Hi,

DA_WIDEMEMO_conversion is used only if actual data has ftWideMemo type:

      ftWideMemo:    begin
        {$IFDEF DA_WIDEMEMO_conversion}
        if (fCorrectType[Index] = 0) and (FDASQLCommand is TDAEBaseDataset) and (TDAEBaseDataset(fDASQLCommand).GetFields[Index].DataType = datMemo) then
          Result := StringToAnsiBytes(TWideMemoField(fld).Value)
        else
        {$ENDIF}
...

in your case, you have datMemo field …

39

yep that won’t be it
so what is the cause…
can’t find the origin as to why it behaves differently between both versions…

40

Does it work with this change?

line 1308:
// datMemo: fWriter.WriteString(VarToStr(val));
datBlob,datmemo: begin
VariantToWriterAsStr(datBlob, val, fWriter);
end;

btw, why you are still using bin1? it was deprecated for several years already

41

my change does solve the problem in reading, haven’t tested what writing gives, but i can’t find the origin of the problem, looking at both versions and since i already had the binadapter unit patched i don’t see why i need to change that line since it was the same in the version i was running and that worked…
so there must be another change triggering this…

bin1 cause we still use DA3 also…

42

DA3 was released 13+ years ago …

I can attach the Upgrading to Data Abstract 4.0 for Delphi article that describes migration from DA3 to DA4+.
also we have v3->v4/v5 Client Conversion Utility (DAConverter.exe).

43

that i know but since we use own getdatasetdata and since we use statement names to select a different sql for the same datatable, it ain’t something the convertor can handle…

if i find the root cause of why this is suddenly handled wrong we can fix it
the legacy is still shipped…