Hello All!

-

Hello All!
I have a problem with the next topic.

I have a stub DLL that creates sample data for my application. I send to the DLL the Firedac Connection I have configured in the main application, and internally the DLL works well, but when the call returns, the main application is not connected. And it's not possible to recover the connection.

I followed all the instructions from this pages:

http://docwiki.embarcadero.com/RADStudio/Tokyo/en/DLL_Development_(FireDAC)

http://docwiki.embarcadero.com/CodeExamples/Seattle/en/FireDAC.DLLSharing_Sample

Does anyone use this technique with success?

Can anyone of you help me? Please!

Is it a known problem of FireDAC or I made something wrong?

Comments

  1. Arioch TheJune 7, 2018 at 1:59 AM

    can u use BPL not DLL ? for object-to-object interactions BPLs are much more native solution

    ReplyDelete
  2. Juan C. CillerueloJune 7, 2018 at 2:07 AM

    Arioch The
    BPL is discarded because is more complicated to control when is charged and when is released.

    But this is not the problem. The problem is that when the process returns from the DLL seems that all the libraries associated with the connection were finished too.

    ReplyDelete
  3. Jeroen Wiert PluimersJune 7, 2018 at 3:35 AM

    CC Dmitry Arefiev

    ReplyDelete
  4. Warren PostmaJune 7, 2018 at 8:56 AM

    Nothing magic happens when a function returns. However I doubt you can share connections between the DLL and the main object if by connection you mean "A connection object".

    Now if when you return from the DLL, you are also unloading and finalizing the DLL, then yes something is happening. You are not explicitly unloading (and thus finalizing) the DLL?


    ReplyDelete
  5. Juan C. CillerueloJune 7, 2018 at 9:26 AM

    Warren Postma
    I'm using the CliHandle pointer passed to create a new TFDConnection inside the DLL with all the parameters. I think this is my error. I'm working to change this, but... it's a lot of work!

    ReplyDelete

Post a Comment