Frédéric

I think I could find a solution which seems to work so far... I kept the TFDSQLiteDriverLink.EngineLinkage = SIFDEStatic only in the main application which loads the other bpls. In the other Bpls I've changed TFDSQLiteDriverLink.EngineLinkage to Default and deleted the FireDAC.Phys.SQLiteWrapper.FDEStat (Automatically replaced by FireDAC.Phys.SQLiteWrapper.Stat by the IDE). With this combination I don't get the error messages anymore (FireDAC.Phys.SQLiteWrappe.FDEStat is missing) during the compilation, and keep the encryption functionnality for all the concerned BPLs. This means the FireDAC.Phys.SQLiteWrappe.FDEStat should be declared only once. As this unit makes all the linking, I'm finally not really surprised ! The strange thing is that it works in 32bit but not in 64bit (The current combination should work with both bitnesses) !

Specifically the EngineLinkage ? This is set to SIFDEStatic. The settings are the same as for 32bits. So as I understand, it should theorically be similar ?

Hello, I have an application which is using packages and SQLite database (encrypted). Unit FireDAC.Phys.SQLiteWrappe.FDEStat is set in the uses in each concerned package. Compiling in 32 bit, there is no problem and all works correctly. Problem starts when trying to compile the packages in 64bit: The compiler asks me to add the FireDACSqliteDriver package, which is already in the required packages (See attached picture). And of course, when starting the application, packages will not load because unit already in package... I need to use the older DLL because of the encryption, this is why I use the static linking. Any idea ? Thanks ! Frederic

IDE library paths can be adjusted without having a project loaded. If your project loads automatically you can start the IDE with the -np flag. If the paths are coming from the project itself, you need perhaps to edit the project file manually ?

Thanks for the tip, I will give it a try !! Frédéric

It's for an existing application, not sure it will be easy to switch to newer functions... Thanks !

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

Bug report is RSS-3599. Wait and see...

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.

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 !

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 ?

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 !!!

Thanks UWE !

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;

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