Re: Memory consumption

"MFS" <noSpam@xxxxxxxxxxxxx> wrote in message
I have problems with memory consumption by ado.recordset object.

The following code from MSDN developers center shows the same probleme,
meaning: if you start the application I would expect, that the memory
consumption shown by taskmanager is fixed on a certain value, but it is
increasing while the application is running.

Can anybody help me with same tipps what went wrong?

I noticed you're using IADORecordBinding in a console app... reminds me of
the diner scene in Pulp Fiction, "if you find my answers frightening you
should cease to ask scary questions." So I think I'll give this detail a
miss... well, just one comment: if for whatever reason you have something
against using the Fields collection, three words: get over it.

Next, this may not address the source of the cunsomption, but I'd bet my
grandma's dentures and her fanciest wig, that it will greatly decrease its
magnitude: instantiate, connect and open the ADO objects *outside* of the
for loop, either pass as parameters or declare at file scope. Doing all
that once, instead of 100,000 times, will surely make a big difference.

Hey, whoa, hold the phone... setting aside for a moment that you don't
specify a provider for your connection... let me get this straight:

1. You create and open a connection, create and open a recordset on a table.
2. You dump the field values of the first row.
3. You assign a date field to a constant value, and update the row in the
4. You dump the field values again.
5. You requery the recordset, and restore the value of the date field.
6. You update the row again, and dump the field values yet again.

* repeat steps 1-6 100,000 times

I see no MoveNext call, so I must assume that either you are processing the
same row 100,000 times, or you are relying on a clustered index, changing
its key to alter the order, to implicitly float a different row to the top
when you creat and open a recordset on the same table, again.

The former would be merely a useless waste of time, cpu and bandwidth.

The latter would be unreliable, it would incur a mind-numbing amount of
needless overhead, would perform like a banana slug... actually, it would be
certifiably insane, for the simple reason that it might be mistakenly
considered functional.

Anyway... sorry... my mind: blown to bits...

Here's your game plan:

1. Get rid of *all* of that data binding crap, immediately if not sooner.
2. Use the Fields collection to get field values, e.g.,

// had to guess at your field names, but assuming these are right...
printf("full name: %s %s",

2.a. Use Fields collection to set values...


3. You are connection to one database, on one server, so
instantiate your connection object one time, call Open
one time

4. You are accessing rows in one table, so you should
instantiate your recordset object one time, call it's Open
method one time

4.a. Even though you only opened the recordset one time,
if by some strange chance there are more than one rows
in the table, you can get to any of them. Check this out,
you'll never guess what it does:


5. If you have a useful purpose for this code in mind, it would
be just grand if you could briefly share it


modified code from:
#import "C:\Programme\Gemeinsame Dateien\System\Ado\msado15.dll"
no_namespace rename("EOF", "EndOfFile")

#include <oledb.h>

#include <stdio.h>

#include <conio.h>

#include "icrsint.h"

// class extracts only fname,lastname and hire_date from employee table

class CEmployeeRs : public CADORecordBinding {


// Column fname is the 2nd field in the table

ADO_VARIABLE_LENGTH_ENTRY2(2, adVarChar, m_sze_fname,

sizeof(m_sze_fname), le_fnameStatus, FALSE)

// Column lname is the 4th field in the table.

ADO_VARIABLE_LENGTH_ENTRY2(4, adVarChar, m_sze_lname,

sizeof(m_sze_lname), le_lnameStatus, FALSE)

// Column hiredate is the 8th field in the table.

ADO_VARIABLE_LENGTH_ENTRY2(8, adDBDate,m_sze_hiredate,

sizeof(m_sze_hiredate), le_hiredateStatus, TRUE)



CHAR m_sze_fname[21];

ULONG le_fnameStatus;

CHAR m_sze_lname[31];

ULONG le_lnameStatus;