I'm a little confused if you should or should not close connection to the EDBSession. Using Delphi XE6 with the latest version of EDB.

I have a TEDBSession, a TEDBDatabase and three TEDBTable when closing the form I close the tables and the database, but if I set EDBSession1.Connected := False I get a EAcces violation error.

I see another thread having a TEDBEngine on the form (Data module) and Tim says just close the TEDBEngine that will close all.

Should I always add a TEDBEngine on a Data Module?

Thanks,
Kim

On 10/7/2020 6:12 PM, KimHJ wrote:
> I'm a little confused if you should or should not close connection to the EDBSession. Using Delphi XE6 with the latest version of EDB.

I would say that generally yes if you're fully done with it but really
it depends on the application design with the overall goal of managing
your app resources.

This might be automatic as you manage your form/datamodule lifecycle as
well - especially with design time components.


> I have a TEDBSession, a TEDBDatabase and three TEDBTable when closing the form I close the tables and the database, but if I set EDBSession1.Connected := False I get a EAcces violation error.

Looks like a bug somewhere in your code as that should not happen - i
would trace it down to identify source of of that AV.


> I see another thread having a TEDBEngine on the form (Data module) and Tim says just close the TEDBEngine that will close all.
>
> Should I always add a TEDBEngine on a Data Module?

That would do it but one does not need really need to use engine for this.

Using engine is useful for some use cases but as a way to close sessions
sounds like pretty bad code design to me personally (I  would reject
something like that during a code review unless there is a really good
explanation why this was done as it might lead to all kinds of side
effects).


Raul

Kim

<<Should I always add a TEDBEngine on a Data Module?>>

Short answer to your question is no. Long answer below, with divergence.


I partly agree with Raul.

Firstly, just in case you are not aware, you can only have one EDBEngine per application. I generally have one on the applications main datamodule, and its only there to allow me to set UseLocalSessionEngineSettings - I could do it using the default engine but I like to see the setting.

You do not say wether you are closing a form that is part of an application or an application. If you're closing an application you have nothing to do.

Assuming you're closing a form that is part of an application then its partly what Raul - its about managing application resources, but unlike the good old days of the BDE its probably nothing you need to worry about. The ONLY reason (in my opinion) for multiple EDBSessions in an application is for separation purposes either across threads or databases that you don't want / can't have touching.

I would also apply that logic to databases - only have multiples for separation. Tables I have vacillated about - there are good treasons to have all tables on one datamodule and good reasons to have separate table instances on each form. I've used both approaches and a mixture as well.

I totally support Raul in that you need to track the AV down. It will probably still occur even if you leave the application to close things down rather than doing it yourself.. I've encountered these sort of AVs when a timer fires and tries to access a table that's been closed (not very often but a swine to track down) or a TDBEdit with an OnChange event which is the most frequent - close the table and the OnChange event can fire and unless you test for the table being closed when the code tries to access the table you get an AV.

In one application I added an appClosing global boolean so I had something easy to test rather than checking multiple tables.

Roy Lambert

Roy Lambert wrote:

<<Short answer to your question is no. Long answer below, with divergence.

I partly agree with Raul.>>

The application have one form, one data module and two thread (one for SMS and one for Email).

I feed the application with json files and depending on what it is it may send email or/ and text.

In this case I just run the app and do nothing then I close it.

When I close the Form (Application since it only have one form) in the OnHide I close all all tables I set the database.Disconnect to False, then if I add a line Session.Close; then I get the access violation.
Without the session close I see in the EDB Server that the session gets removed.

I have some modules running on the EWB using EDB. Each module have a diffrent user and I see in the EDB Server that I have old sessions that did not close, that is the reason I was looking into the Session.Close.


Kim

On 10/8/2020 12:17 PM, KimHJ wrote:
>
> The application have one form, one data module and two thread (one for SMS and one for Email).

Make sure you have 3 unique instances of the session - you main UI
thread (form) needs one and each of the threads needs their own as well.

If session and other components are on your datamodule and you create 3
instances you are probably OK as long as you follow the rules :

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2&product=rsdelphiwin32&version=10.4&topic=Multi_Threaded_Applications

> When I close the Form (Application since it only have one form) in the OnHide I close all all tables I set the database.Disconnect to False, then if I add a line Session.Close; then I get the access violation.

This takes care of main UI session - how do you shut down threads.

> Without the session close I see in the EDB Server that the session gets removed.

This is probably due to app exiting


> I have some modules running on the EWB using EDB. Each module have a diffrent user and I see in the EDB Server that I have old sessions that did not close, that is the reason I was looking into the Session.Close.
>

Need more info on details here but old sessions might indicate something
that was not closed and app crashing so EDB shutdown logic did not kick
in either

Raul

Kim


This time I can fully agree with Raul

WHere you're using EWB are you connecting over the internet? If so the "old sessions" can represent occasions where, as Raul suggests, the app was not closed gracefully or the internet connection was lost. If you get a lot of these look at the dead session cleanup times for the server so that they are removed more quickly.

Roy Lambert

Raul wrote:

>> When I close the Form (Application since it only have one form) in the OnHide I close all all tables I set the database.Disconnect to False, then if I add a line Session.Close; then I get the access violation.<<

>This takes care of main UI session - how do you shut down threads.<

Raul,
I'm just opening the application, don't do anything except open the database, the threads are never excuted.


Each thread create theier own session, database and tables and they free them when the thread is finish.

Kim

Hi Kim,

> I have a TEDBSession, a TEDBDatabase and three TEDBTable when closing the form I close the tables and the database, but if I set EDBSession1.Connected := False I get a EAcces violation error.

Any chance you have SQL Statement Caching enabled on the session?  If so, try calling  EDBSession1.FreeCachedSQLStmts('') before you attempt to close the session.   I reported an issue yesterday for something very similar and this is the workaround that I found for it.  Hopefully the workaround works for you as well.

Terry

Terry Swiers wrote:

>>Any chance you have SQL Statement Caching enabled on the session?  If so, try calling  EDBSession1.FreeCachedSQLStmts('') before you attempt to close the session.   I reported an issue yesterday for something very similar and this is the workaround that I found for it.  Hopefully the workaround works for you as well.<<

Hi Terry,

Thanks, I tried it didn't work.

Kim