Blocking error with access violation using Firedac sql monitor in uniGUI

[Graziano Paesani]

I set up a Firedac connection and a FDMoniFlatFileClientLink for each uniGui session. In the firedac connection I added the parameter 'MonitorBy=FlatFile'. I then configured FDMoniFlatFileClientLink to generate a log file whose filename depends on the session id. When starting the first session it works correctly, if I launch a new session the uniGui application crashes and generates the access violation error. How can I solve the problem? Is there a best practices and a demo for using a firedac sql monitor on uniGUI applications?

 

I use:

Embarcadero® Delphi 10.3 Version 26.0.33219.4899 

uniGUI Professional Edition v1.90.0.1564

[Sherzod]

Hello,

10 minutes ago, Graziano Paesani said:

uniGUI Professional Edition v1.90.0.1564

Please adjust your forum email address:

 

[Skyp]

On 9/4/2023 at 12:11 PM, Graziano Paesani said:

I set up a Firedac connection and a FDMoniFlatFileClientLink for each uniGui session. In the firedac connection I added the parameter 'MonitorBy=FlatFile'. I then configured FDMoniFlatFileClientLink to generate a log file whose filename depends on the session id. When starting the first session it works correctly, if I launch a new session the uniGui application crashes and generates the access violation error. How can I solve the problem? Is there a best practices and a demo for using a firedac sql monitor on uniGUI applications?

 

I use:

Embarcadero® Delphi 10.3 Version 26.0.33219.4899 

uniGUI Professional Edition v1.90.0.1564

I answer for information (for everyone):
It will work if -
For each session, create a separate monitor instance(example in mainmodule)(a unique log file) (for connections used by this session).

 

Create connection:

1. If you are trying to create a single pool of connections (fd, unidac - the pool code already has synchronization methods) per process, then you need to unbind the connections from the owner Connection.Create(nil) and control the life cycle of connections and dependent components yourself..

2. If you are not ready to resort to such control, then create connections + pool(a pull will be created for each session.. it bad..) for each session in the mainmodule address space.... and in the case of using Task, Threads within a unigui session, you will have to wrap the constructor and destructor in a monitor:
lcmpown:= con.owner;
if assigned(lcmpown) then
begin
Tmonitor.enter(lcmpown); freeandnil(con); tmonitor.exit(lcmpown);
end;
this is due to the operation of notifications and mechanisms for creating and clearing components.

 

both options imply SQL monitor for session (in mainmodule)