Firedac Unicode v roznych verziach Delphi

[Hannibal]

Zdravim

Delphi 10.2.3
ms sql db 2019
Firedac
    TFDquery ,TFDStoredProc -  vsetky ParamByName('').asString  - funguju ako unicode. 

updatli sme na Delphi 10.4.2
    TFDquery , TFDStoredProc -  vsetky ParamByName('').asString  - funguju ako ANSI.  !!!
Data nacitane z DB ako unicode. pri zapise spat su vsetky unicode znaky skonvertovane na '??'

Preco ? Stretol sa s tym niekto?





 

[Radek Červinka]

Hmm, je pravda ze je zmena v TFDParam.SetAsStrings proti 10.2.x (predtim tam bylo FDataType := ftWideString ) viz FireDAC.Stan.Param.pas

Kód: [Vybrat]

procedure TFDParam.SetAsStrings(AIndex: Integer; const AValue: String);
begin
  if not (FDataType in [ftString, ftFixedChar, ftWideString, ftFixedWideChar]) then
    FDataType := {$IFDEF NEXTGEN} ftWideString {$ELSE} ftString {$ENDIF};
  Values[AIndex] := AValue;
end;
ale to je jen v pripade ze parametr neni daneho typu. Jakeho typu je ten parametr?

[Radek Červinka]

Pripadne  kdyz das .AsWideString v tech pripadech kdy neni jasny typ?

[Hannibal]

CustomQuery.Create(AOwner: TComponent);
begin
  inherited;
  UniDirectional := False;
  FClearEmptyParams := True;
  FormatOptions.DefaultParamDataType := ftWideString;   << toto tam mame. ale je to ignorovane. v priradeni sa vo firedac vyhodnoti NEXTGEN direktiva
  a prepise typ na ftString
end;

[Hannibal]

Spravili sme replaceall asString >> asWideString.
Problem odstraneny.

Zial na stratu dat nas upozornil zakaznik. A je to velmi nemile prekvapenie, nieco funguje bez problemov X rokov, v delfi release notes 10.4 ani tuk o zmene vo firedacu, a zrazu sup a data v prdeli. Stacilo k tomu len skompilovat v novej verzii delfi.
 

[Hannibal]

a k tomu NEXTGEN - v release notes maju ze je v  10.4 sydney odstranena direktiva.

tak neviem preco z nejakeho zahadneho dovodu ale pribudla do firedacu. 

[pf1957]

Zial na stratu dat nas upozornil zakaznik. A je to velmi nemile prekvapenie, nieco funguje bez problemov X rokov, v delfi release notes 10.4 ani tuk o zmene vo firedacu, a zrazu sup a data v prdeli. Stacilo k tomu len skompilovat v novej verzii delfi.

Ja se nad chybami tohoto charakteru vzdycky nestacim divit: to k*rva nemaji continuous integration a nepousteji automaticky unit testy?

[Radek Červinka]

a k tomu NEXTGEN - v release notes maju ze je v  10.4 sydney odstranena direktiva.

tak neviem preco z nejakeho zahadneho dovodu ale pribudla do firedacu. 

Zial na stratu dat nas upozornil zakaznik. A je to velmi nemile prekvapenie, nieco funguje bez problemov X rokov, v delfi release notes 10.4 ani tuk o zmene vo firedacu, a zrazu sup a data v prdeli. Stacilo k tomu len skompilovat v novej verzii delfi.

Ja se nad chybami tohoto charakteru vzdycky nestacim divit: to k*rva nemaji continuous integration a nepousteji automaticky unit testy?

Nesmysl:
a) soucasti jsou testy budovane pres 20 let, ale neco se podchytit neda, zrovna tohle je podle mne dost specificke
b) pro integraci se pouzivaji nastroje + neco co se jmenuje Crucible nebo tak nejak
c) FormatOptions.DefaultParamDataType = Specifies the default data type for parameters with ftUnknown data type
d) muzu tedy vedet jaky typ maji opravdu ty parametry v okamziku .AsString? protoze ta zmena je jen pokud ten typ neni ftString, ftFixedChar, ftWideString, ftFixedWideChar. Je to opravdu fdUnknown aby se pouzilo to FormatOptions.DefaultParamDataType ?

[pf1957]

a) soucasti jsou testy budovane pres 20 let, ale neco se podchytit neda, zrovna tohle je podle mne dost specificke

Tak IMHO zrovna tohle je problem, ktery se da na urovni unit testu bezproblemove otestovat.

Jinak to vypada, ze je to nejaky proces sjednocovani, protoze u TFields.AsString to po unicodifikaci z nejakeho duvodu nechali na ANSI, zatimco u TParam natvrdo nastavovali ftWideString. Nicmene bez ohledu na takovou zmenu bych ocekaval, ze na zkomoleni textu pri ceste do/z DB maji unit testy.

[vandrovnik]

A on je nějaký rozumný dovůd, proč by AsString měl být Ansi string? Čekal bych, že všude bude "normální" string a naopak třeba přidají něco jako AsAnsiString pro situace, kdy je to z nějakého důvodu potřeba.

[pf1957]

A on je nějaký rozumný dovůd, proč by AsString měl být Ansi string? Čekal bych, že všude bude "normální" string a naopak třeba přidají něco jako AsAnsiString pro situace, kdy je to z nějakého důvodu potřeba.

To byl nejspis nejaky pokus o zpetnou kompatibilitu, protoze pred unicodifikaci tudy lezly ANSI stringy. Ono to nejspis zadne dobre reseni nema.