ADOCE3.1 memory leaks using SQL SELECT
Hartmut Melchin
I'm developping an application using eVC and ADOCE3.1. I use the
objects CVOConnection and CVORecordset downloaded from Virtual Office
Systems.
I know about the problems of the leak caused by the CreateObject
function and I avoid them usign global objects.
My application is multithreaded and in each thread I initialize the
COM library with CoInitializeEx(...).
I'm working on a MINCOMM platform, but it does not seem to be a
problem.
ADO ist working, but when executing a sql query "SELECT <fields> from
<table> where <condition>" statements, the global memory status
(GloblaMemoryStatus) indicates loosing much memory. I'm sure to free
everything, but it does not help. Can anybody gibe me a hint what's
going on ?
Here is the part of the code which causes the leaks :
// m_rs is a CVORecordset member of a global object
m_rs.Open( _T( pwszQuery, adOpenForwardOnly, adLockOptimistic );
if( m_rs.IsOpen() && m_rs.GetRecordCount())
{
m_rs.MoveFirst();
// my code walking through the recordset
// the leaks do not disappear, if I comment it out
m_rs.Close();
}
it works fine, but there are memory leaks.
regards
Hartmut
Earl
"Hartmut Melchin" <h.me...@ca-computer-automation.de> wrote in message
news:1aecca2d.03020...@posting.google.com...
Keld Laursen
news:O6W6clTzCHA.640@TK2MSFTNGP12...
> Set the rs = nothing after you close.
As this will require you to CreateObject a new recordset, this will leak
memory.
> "Hartmut Melchin" <h.me...@ca-computer-automation.de> wrote in message
> news:1aecca2d.03020...@posting.google.com...
> > m_rs.MoveFirst();
> > // my code walking through the recordset
> > // the leaks do not disappear, if I comment it out
> > m_rs.Close();
> > }
> >
> > it works fine, but there are memory leaks.
Hartmut: Are you sure that you doesn't just hog a chunk of memory here, and
not really leaking it? I could think of several reasons that creating a
largish recordset will eat up a lot of memory, but on a once-off basis. This
memory should be re-used on subsequent recordset opens.
I am using code like yours in lots of places in one of my programs, and
after a while I have had a lot of selects in various recordsets. This brings
the total memory use up till around 8MB for my app, but when it reaches that
peak, it stabilises.
I had the CreateObject leak originally. That would add an extra around 1 MB
of memory to my program each time I re-created my recordsets.
Keld Laursen
Hartmut Melchin
I use global objects to prevent from the CreateObject memory leak, so
I cannot release the recordset. Even if I do so, it does not change
anything.
kind regards
hartmut
"Earl" <brik...@comcast.net> wrote in message news:<O6W6clTzCHA.640@TK2MSFTNGP12>...
Hartmut Melchin
>
> Hartmut: Are you sure that you doesn't just hog a chunk of memory here, and
> not really leaking it? I could think of several reasons that creating a
> largish recordset will eat up a lot of memory, but on a once-off basis. This
> memory should be re-used on subsequent recordset opens.
> I am using code like yours in lots of places in one of my programs, and
> after a while I have had a lot of selects in various recordsets. This brings
> the total memory use up till around 8MB for my app, but when it reaches that
> peak, it stabilises.
> I had the CreateObject leak originally. That would add an extra around 1 MB
> of memory to my program each time I re-created my recordsets.
>
> Keld Laursen
Yes, I'm sure that there were memory leaks.
But I found the solution. It relies on the objects CVOConnection and
CVORecordset. They are imlemented very bad concering the COM
specifications. There are memory leaks because the recordset does NOT
FREE the fields object. Opening a recordset causes the fields object
to be refered and there is not call to the Release() function.
Now I've implemented my own CadoXXXX Objects and I took care of the
COM reference counting. The memory leaks disappeared completely. I
would strongly recommend to every user of these CVOxxxx objects to
implement a correct reference counting.
regards
Hartmut