bugs://77858 got closed with status fixed.
pls update uDABin2DataStreamerSupport.pas as
function Bin2_ReadVariantFromStream(Stream: TStream; DataType: TDADataType): Variant;
..
datGuid: Result := AnsiBytesToString(Bin2_ReadGUIDFromStream(Stream)); //<<<<<<<<<changed
Thanks will give it a go. Is this another FireDAC change/issue by any chance?
not yet.
it just incorrectly translates content of TBytes into Variant so we need to use TBytes->String->Variant for getting valid Guid
Yes that’s fixed it, thanks.
So is this something they’ve changed in Delphi itself? Just trying to understand why this has suddenly started happening.
we have stopped usage of AnsiString & UTF8String in favor of String for compatibility with NEXTGEN compiler and looks like case with guid processing was missed from our tests or it was tested with non-unicode versions of Delphi only.
Ah ok that makes sense. I’d already noticed the removal of UTF8Strings, primarily in the logon service.
I’m now investigating another very weird error in our code which seems similar.
I’m getting an exception thrown during an ApplyUpdates which is because a GUID string value is incorrect, containing only an opening curled brace. I’m not sure why this is yet but, when the ProcessError function of my business processor is called, it appears that all the string values accessed via the strongly typed properties are corrupted and displaying as random Chinese characters.
This appears only to happen when a LocalDataAdapter is used on the server itself. When an RDA is used on the client it’s fine.
Do you have any ideas on this as I’m lost and, given the previous issues with strings, I’m concerned it could be something related.
can you create a simple testcase, pls?
from symptoms - it seems that widestring was read as ansistring …
That could be tricky as I’m not entirely sure what’s going on just yet but I’ll try.
Here you go. Again a simple test project created using the wizard with an SQL script to create the database.
As you can see, it works client-side but not server-side, seems to be an issue with the LDA and nvarchar(max) fields.
StringTest.rar (112.8 KB)
Thanks, logged as bugs://77941
bugs://77941 got closed with status fixed.
pls update uDALocalDataAdapter.pas as
procedure SetDestValues_BatchMode;
var
s: UnicodeString; //changed
..
datGuid: begin
buf3:= StringToAnsiBytes(VarToStr(val[i]));
Move(buf3[0], pointer(buf1)^, 38 {Length(GuidString)});
end;
datBlob,
datMemo: begin
buf3 := VariantToBytes(Val[i]);
PPointer(buf1)^ := aDataForAppend.lBatchAdding.MakeBlobFromBytes(buf3);
end;
datWideMemo,
datXml:begin
s := VarToUnicodeStr(Val[i]);
c:=Length(s)*SizeOf({$IFDEF UNICODE}Char{$ELSE}WideChar{$ENDIF});
SetLength(buf3,c);
if c > 0 then Move(s[_StrLow],buf3[0],c);
PPointer(buf1)^ := aDataForAppend.lBatchAdding.MakeBlobFromBytes(buf3);
end;
Note: This fix will be in next week’s beta.
Ok thanks I’ll give it a try.
I have to say I’m rather concerned about this. This is the third bug I’ve found since upgrading to Delphi 10.2 and the latest RODA release about a month ago and collectively they’ve cost me quite a bit of time.
I’ve just found another instance of this with more rubbish Chinese characters. I now need to try to track this down.
Have you found any more bugs with these UTF8String changes in this version that we should know about?
I’ve fixed a bug with DARemoteCommand recently.
see details in Chinese command name can’t work topic
I’m not using remote commands unfortunately. I’m trying to get this reproducible then I’ll trace through and try to find out exactly where it’s going wrong.
Are you using the latest DA release (9.2.103.1311) ?
it contains 78026: DAD: problem with Chinese characters in Chinese locale.
No I’m on 9.2.101.1295 still. If I can get this reproducible then I’ll try updating and see if it helps.