• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2421
  • Last Modified:

ADOQuery dont free up memory when freed

HI

I Am working on a application which uses ADOQuery to access my
database. I Have to be able to create and then free the query when done, it
works ok except that the memory is not freed completely, and my application
eventualy dies.

This little code snippet demonstrates the problem, can anyone help me
find a solution.

For this test i simply created a form with a button when clicked excutes the following

I Use Delphi 7

  Coinitialize(nil);
  for i := 0 to 99 do
  Begin
    Query := TADOQuery.Create(nil);
    query.ConnectionString := ANY CONNECTION STRING;
    Query.SQL.Clear;
    Query.SQL.Insert(0,'SELECT * FROM table');
    Query.Open;
    Query.Close;
    Query.Free;
    Query := nil;
  End;
  Couninitialize;

Thanks

Erik



0
erik_aaskoven
Asked:
erik_aaskoven
  • 4
  • 3
  • 3
  • +3
5 Solutions
 
lamtl354Commented:
your code seems use alot of memory every time you
 - create a new instance of ADOQuery,
 - open & close Database connection,
 - select with same query

if that was the case, i suggest
 - create ADOQuery once,
 - Open & close if really need.
 - use paramsbyname

hope helps
0
 
erik_aaskovenAuthor Commented:
Creating the Query once is not a possibility, because my application is multithreaded, I need to create when the thread starts and free when the thread ends.

The problem is that the Thead finishes OK, but memory is still allocated somewhere?

The above example is only to demonstrate the problem, not an actual function in my program.

Hope to get more suggestions

Erik
0
 
CryonieCommented:
Why don't you use query.Destroy ?

.Destroy free memory used by the object.


Manybe that would help ... :)
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
erik_aaskovenAuthor Commented:
Tried that, it does not work.  .free calls the objects destroy

But i have tried to just

Create and then free without adding sql, opening and closing, then there is no leak, it seems like the leak only appears when sql is inserted.
Only inserting SQL and not open and close the dataset still generates the same amount of memoryleaks
0
 
CryonieCommented:
And if you do a query.Clear before you destroy it?
0
 
erik_aaskovenAuthor Commented:
I expect you mean query.sql.clear??

In that case no difference
0
 
JeePeeTeeCommented:
Do you have the latest version of...

http://www.microsoft.com/downloads/details.aspx?FamilyID=6c050fe3-c795-4b7d-b037-185d0506396c&DisplayLang=en

because....

When marshalling an ActiveX Data Objects (ADO) recordset between processes the handle count incrementally increases for each call made to the out-of- process component. This behavior only occurs if the rowset contains more than 8K of data.

regards
JeePee
0
 
erik_aaskovenAuthor Commented:
Yes i have the latest MDAC.

The memory leak occurs even when not opening and closing the query. And therefor also with very small dataset <8kb

I think the leak is comming from the query.SQL(something), but i dont know....

Erik
0
 
JeePeeTeeCommented:
The following modules are leaking at my place....

msado15.dll and w3mifxxx.dll (Pervasive SQL/2000). No leaking code in my project1.exe.

JeePee
0
 
JeePeeTeeCommented:
This is my current score....

Total Memory Leaks 19.900 1.275.200
   Nested Leak 19.900 1.275.200
   Nested leak 400 13.000 msado15.dll ! 0x000057EC
   Nested leak 100 1.400 msado15.dll ! 0x00008532
   Nested leak 400 240.000 W3BIF133.DLL ! 0x0000F019
   Nested leak 9.300 390.400 W3BIF133.DLL ! 0x00007AF0
   Nested leak 400 240.000 W3MIF137.DLL ! 0x00024941
   Nested leak 9.300 390.400 W3MIF137.DLL ! 0x0001C97E

1 digit is number of leaks encountered.... 2nd digit is the number of bytes lost... 3th part is the module and finally the entrypoint....
0
 
DelphianCommented:
Hi
I'm almost sure that the problem is
the OLE Db Provider. Actualize your
client connectivity from the Pervasive
producer.

I have this opinion because only the
ADO gateway library (msado15.dll)
and the Ole Db DLL (W3BIF133.DLL)
 are leaking. And our systems don't
leak here, but the difference is that
we use MS SQL Server here.

Update and/or reinstall the client tools
for Pervasive SQL.

[]s Fabricio
0
 
Ivanov_GCommented:

  Here is the problem :

  Query := TADOQuery.Create(nil);
 
  try

  Query := TADOQuery.Create(Form1); // instead of Form1 - Self possible
0
 
DelphianCommented:
Ivanov_G:
This is not the problem. The author freed the query
(called Query.Free) so the ownership is not the root
of the problem here.
See the code:
Query := TADOQuery.Create(nil);
.
.
.
.
Query.Close;
Query.Free;

Since he called Query.Free, the absence of
a owner is not a problem.


My thinking is that the pervasive SQL OLE DB driver is leaking,
based on the stats he showed.
0
 
DelphianCommented:
Hi,
Please update the question.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

  • 4
  • 3
  • 3
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now