Database connection

[LogSistemas01]

Hello people,

I'm starting at Unigui and doing VCL conversion. My team and I have the following scenario regarding connection to the database.

We have a class that manages the connection to the database. Every time it is needed, it is created and connected to the database, and after completing the process it is destroyed. This way, at various times, the application will not be connected to the bank.

In the other case, it would be to have the connection component in the MainModule connected all the time.

I would like to know what you think would be better in terms of consuming less resources, since one option stays connected all the time and the other makes several connections?
If anyone has or has had this scenario and can give some feedback, I would be grateful.

Any tip is welcome.
Thank you!

[NelsonFS]

Transform you system to work with rest server.. uses DataSnap or RestDataware.

Each procedures/functions will create a connection in runtime, execute, and return a json.

In UniGUI project, create process to call this rest server e process this json.

In future, you architecture will works with any type of client side and will consume lowerest resource.

[Mehmet Emin]

This advice is if you are using FireDAC but should be possible with other libs.

To keep minimum database connections  at any one time, use "offlining connection" option of FireDAC combined with "connection pooling".

This way you open the connection when you require and do your job and put it back to offline mode.

These links has the information

http://docwiki.embarcadero.com/RADStudio/Rio/en/Offlining_Connection_(FireDAC)

http://docwiki.embarcadero.com/RADStudio/Rio/en/Multithreading_(FireDAC)     (Connection Pooling)

Also check uniGUI docs for proper use of FireDAC components in multi threaded apps.

 

[LogSistemas01]

52 minutes ago, NelZ said:

Transform you system to work with rest server.. uses DataSnap or RestDataware.

Each procedures/functions will create a connection in runtime, execute, and return a json.

In UniGUI project, create process to call this rest server e process this json.

In future, you architecture will works with any type of client side and will consume lowerest resource.

Yes, we are studying restdataware.
But until we learn, we are in that situation.

But thanks for the advice.

But what did you say, does restdataware automatically create and destroy the connection?

Thank you again!

[LogSistemas01]

40 minutes ago, Mehmet Emin said:

This advice is if you are using FireDAC but should be possible with other libs.

To keep minimum database connections  at any one time, use "offlining connection" option of FireDAC combined with "connection pooling".

This way you open the connection when you require and do your job and put it back to offline mode.

These links has the information

http://docwiki.embarcadero.com/RADStudio/Rio/en/Offlining_Connection_(FireDAC)

http://docwiki.embarcadero.com/RADStudio/Rio/en/Multithreading_(FireDAC)     (Connection Pooling)

Also check uniGUI docs for proper use of FireDAC components in multi threaded apps.

 

Nice! Thank you!! I didnt know about "offlining connection".

[NelsonFS]

20 minutes ago, LogSistemas01 said:

Yes, we are studying restdataware.
But until we learn, we are in that situation.

But thanks for the advice.

But what did you say, does restdataware automatically create and destroy the connection?

Thank you again!

Inside RestDataware, you can create a method and publish it, creating a connection object variable (like firedac / zeos), process it and finally destroy it.
Or, you can use the one automatically configured by RESTDWDataBase. TServerMethodDataModule is always created automatically and destroyed.
As for using Firedac with cache, be careful when synchronizing when the connection returns.
Because another user can change the data that was cached on another computer, there you have to work with concurrency errors, in addition to the risk of losing launches due to the permanent loss of connection. In this case, the user complains that he made many postings and lost the records.
This cache option is great if the user continues to include / change / exclude and maintain search data, but when he returns online, you have to deal with problems that may appear.
Attention, the server should not keep too much in cache, otherwise you will have a lot of problems with high memory consumption and risk of deadlock in the tables.
In my opinion, the best thing is to keep the memory on the server side to a minimum. Because when the server goes down, or returns, everything continues.
If you had caches, there are problems with restoring the point you were on.
And that is what the REST way of working has the advantage.

[LogSistemas01]

I understood.
With rest it seems to be simpler and safer.

Thank you for the tips.

[ahmed.atayib]

i am in the same situation and decided to go with Rest API. 

i will consider Tms XData for server side if i go with delphi as back end, but for now i am studying how is it easy to use  Asp net core as back end for delphi interface.

[LogSistemas01]

Search for Horse for delphi.

It's extremely easy.