Jump to content

Frédéric

Members
  • Content Count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the tip, I will give it a try !! Frédéric
  2. It's for an existing application, not sure it will be easy to switch to newer functions... Thanks !
  3. Hello; Not sure it's the most appropriate way to report it... I've added the RSA_verify prototype, so we can directly call it. RSA_verify : function (type1: Integer; m: pointer; m_len: longword; sigbuf: PAnsichar; siglen: longword; rsa: PRSA): Integer; cdecl = nil; Attached the modified file. It would be nice to include the modification in the SVN. Thanks ! Regards Frederic OverbyteIcsLIBEAY.pas
  4. Frédéric

    FireDAC encrypted SQLite DB with Delphi 12.3 x64

    Bug report is RSS-3599. Wait and see...
  5. Frédéric

    FireDAC encrypted SQLite DB with Delphi 12.3 x64

    Sorry, wrong information, I've checked it with the 32bit version, problem remain the same with the 64bit version. This gives an answer if the encryption method should also be separated between 32 and 64bits. I will make a sample to be able to report the problem to embarcadero.
  6. Frédéric

    FireDAC encrypted SQLite DB with Delphi 12.3 x64

    I've recompiled my encryption tool also with Delphi 12.3 and also in 64bit. Now it works ! At the moment not sure if my encryption tool (Really nohing special, simply using TFDSQLiteSecurity to make the encryption) was simply outdated or we need to do a bitness wise encryption to make it work. This would mean we cannot share the same database between the same 32 and 64 application. Seems weird... I will be able to do more tests regarding this in the next few days... Thanks !
  7. Frédéric

    FireDAC encrypted SQLite DB with Delphi 12.3 x64

    Yes, the sqlite3_fde_x64.obj should be used in this case. Again it works in 32bits but not 64 (with exact same database of course). Theorically it's way 3 that I use. But as it happens also directly in the 64bit IDE I suspect a bug in the embarcadero libraries ? Has someone used succesfully the same cases ?
  8. Hello, I'm using a SQLite (aes-128) encrypted database. If I compile the application in 32bit then it works correctly and the database can be opened. The same application + same database compiled in 64bit generates an AV in FireDACSQliteDriver290.bpl (Read of FFFFFFFFFFFF...). The database can be opened in the IDE 32bit but same error if I try to open it in the 64bit IDE. 'Engine linkage' is set as slFDEStatic and I have only FireDAC.Phys.SQLiteWrapper.FDEStat unit in the uses. Note: the same non encrypted database can be opened in the 64bit IDE but I have the same problem when starting the application. Is this something known ? Thanks !!!
  9. Frédéric

    TGUID to Json

    Thanks UWE !
  10. Frédéric

    TGUID to Json

    Yes, of course! Here the code snippet: interface uses REST.JsonReflect; type TGUIDInterceptor = class(TJSONInterceptor) public constructor Create; function StringConverter(Data: TObject; Field: string): string; override; procedure StringReverter(Data: TObject; Field: string; Arg: string); override; end; MyClass = class(TObject) private [JSONReflect(ctString, rtString, TGUIDInterceptor, nil, true)] FJobUID: TGUID; published property JobUID: TGUID read FJobUID write FJobUID; End; implementation uses System.Rtti; { TGUIDInterceptor } constructor TGUIDInterceptor.Create; begin inherited Create; ConverterType := ctString; ReverterType := rtString; end; function TGUIDInterceptor.StringConverter(Data: TObject; Field: string): string; var ctx: TRTTIContext; begin Result := GUIDToString(ctx.GetType(Data.ClassType).GetField(Field).GetValue(Data).AsType<TGUID>); end; procedure TGUIDInterceptor.StringReverter(Data: TObject; Field, Arg: string); var ctx: TRTTIContext; LValue: TValue; begin var vGUID := StringToGUID(Arg); TValue.Make<TGUID>(vGUID, LValue); ctx.GetType(Data.ClassType).GetField(Field).SetValue(Data, LValue); end;
  11. Frédéric

    TGUID to Json

    Hi Stefan, Thanks for pointing to the QC Issue. I've just put an JSONReflect attribute on the concerned fields of my objects so now it works like I need. OK the undesired format in one thing but yes it should produce something out of the box. The output format can already be adjusted case by case, or possibly an option to choose the output format. Regards
  12. Frédéric

    TGUID to Json

    Hello, I'm currently using RAD Studio 11.2 and just wondering why the standard Delphi Json library (Rest.Json or Data.DBXJsonReflect) is not able to serialize a TGUID value ? Is this possible or I am missing something ? It fails with an 'insufficient RTTI available to support this operation' error. Sure I can add a converter, but it should at least be converted as a record (or to a string), or no ? How should this be handled ? Thanks ! Frederic
  13. Hi, Fine it works. I didn't check the result, but at least it doesn't make the compiler fail !!! Thanks a lot for your work !!!
  14. Hi, yes of course, but I was just wondering if it is a known bug of the fixpack or if I'm doing something wrong. Thanks I didn't catch there are some entries for IDEFixpack
  15. Hello, On my RAD Studio 10.3.2 with IDE Fixpack 6.4.4 installed I get a Compiler Fatal error when I pass the -x-cgo compiler option: [dcc32 Fatal Error] frmMain.pas(36): F2084 Internal Error: AV1335D091(0D0F0000)-R00000001-0 This happens when the compiler encounters a simple integer division: function TForm1.DoDivision(AValue: Integer): integer; begin result := AValue div FIntegerField; end; By removing the -x-cgo option the compiler is happy again ! I have all the latest hotfixes install (at least the ones I know :-) ) I didn't get this error with Delphi 10.2.3 version and IDE FixPack 6.4.2. Is this a known problem or is something wrong with my installation ? I verified twice and couldn't find anything wrong... Perhaps important info, I have both 10.3.2 and 10.2.3 installed on same VM. But I left some paths to be sure the compiler doesn't catch some wrong files. It seems OK from this side. Frederic
×