Problem to destroy Delphi’s DM

Asked

Viewed 408 times

1

In the system we use Delphi DM to do SQL command, but they are called screen on screen, and sometimes one screen uses the other (or more). Only this causes memory overflow, to solve, I’m killing the DM after closing the screen, but has some method ready to check from time to time the open ones without use and close them?

delphi

2 answers

1

It’s peaceful to do this:

if (DM <> nil) then // Se é diferente de nulo
begin
  DM := nil;
end;

Or where I mentioned DM := nil; you can pass FreeAndNil(DM);

Examples to avoid Access Violation:

 Abriu Cadastro de Clientes --> DM Aberto.
 -- Abriu Tela que procura Estados --> Essa tela usa DM.
 -- Fechou a Tela que procura Estados --> Não pode fechar o DM
Fechou o Cadastro de Clientes --> Pode fechar o DM

This way you will make the control of the screens that uses the Main DM, however, the correct is the main DM always stay open while the application runs, create secondary Dms as DMClientes, DMetcetc... This way when closing the Customers screen you close the DMClientes and your application will not be depending on anything else from this DM!

  • Right, but if another screen is using it, it won’t destroy the values there giving access Violation??

  • Open without use does not have as a friend, and yes, it goes from Access Violation! Right is taking the method I passed to you and every time you close a Screen that uses DM if it is not going to use more passes the closing method! On my system, I have 1 main DM that always stays open and I have small Dms for each screen that has to open and close frequently!

  • The problem is that I destroy one that may be being used by another screen of the access Violation, because the DM was "destroyed". This is my doubt, besides having to do a check on all the code to check this, there is something "done", to check if that MD is being used by a parent window(even if it is 3 windows before for example)?

  • To my knowledge you have no friend, the only way is to control it yourself! I will edit the answer by showing examples of how to control!

0

Based on what you describe and without the code to know what you are doing, it is a little difficult to help you. But come on.

One approach would be to put, in these DM’s, the basics of the basics. That is, only the Datasets you will actually use. Anything that is accessory, you can create at runtime. In this case, the inheritance can help you a lot, leaving the repetitive part of the code in Dmpai.

Another thing that can help is using create a connection Singleton or create a pool. Depending on the bank you are using, it may be that the many transactions/connections are holding too much resource without releasing. With Singleton/connection pool, you can decrease this possibility of error.

Another question is: Clean the house before you leave the DM. Close DataSet's, close active transactions, close connections (or return them to the pool). Another detail is that if you are using the TFDQuery, and creating it at runtime, ensure it will destroy it (Try... finally) using Release instead of Free direct. The method Release makes memory releases that the .Free doesn’t. Don’t ask me why the two are public, because I don’t know.

Finally, if your project allows you to work with the same instance of DataModule, you only need to build a factory and a English class to return the DM you need.

Browser other questions tagged delphi

You are not signed in. Login or sign up in order to post.