I have a rather {*filter*} problem with an ATL COM object I've created. Basically
it imports documents into a document database. The number of documents tends
to be very large, up to maybe 30,000 in one process.

To avoid possible memory problems, I'm doing 1000 at a time, storing data
intermediatary in an STL list, where the data is released after each
insertion into the database. Now my problem is, when approx. 2700 documents
have been inserted into the database (requires insertion into 4 different
tables), OLE DB suddenly stops and reports an HRESULT of E_OUTOFMEMORY. This
is with the new MDAC 2.5, using the OLE DB ODBC provider against an Oracle
7.3.4 database, using the Oracle 7.3 Ver 2.5 (2.05.03.01) ODBC driver.

Now, if I monitor the memory usage, for each batch of documents, the 12 Mb
is quickly eaten by the STL list for storage of the document data before
insertion. Then each element is processed and deleted from the list, and the
memory usage slowly goes down as it progresses. However, after one such
batch of documents, memory usage has increased by 2Mb, when it should have
stayed level with usage before the batch (everything seems to be released,
as far as I have control). During the third batch (memory still going down),
OLE DB gives up and returns E_OUTOFMEMORY.

I wonder why... What I've tried... Before each batch, I've tried to close
and release the CDataSource and CSession objects, and create them anew. No
effect whatsoever. I've tried to delete the CCommand<CManualAccessor> object
before using it again in the same function. No effect whatsoever. Not that I
expected an effect...

Anybody got any ideas? Oh, both database server and computer running import
is NT Server 4.0 SP5.

I'm stumped...

Cheers,
Dan Lewi Harkestad

Something like a list.clear()  ? (I'm just guessing here, I don't have my
STL book out).

Nick

Well, I've got a map in one of the objects I'm using which weren't cleared
before the object were destroyed. However, clearing the map had no impact on
the memory loss. The other list is losing its members one by one, so at the
end, it's cleared.

Cheers,
Dan