Article View: comp.database.ms-access
Article #4Re: ADO Memory Leak - Please Help
From: Val Mazur
Date: Fri, 12 Jul 2002 13:17
Date: Fri, 12 Jul 2002 13:17
138 lines
6264 bytes
6264 bytes
Hi,
Check if this is not your case.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q247140
I think you would need to close your connection periodically to free you
allocated memory
--
Val Mazur
Microsoft MVP
"Paul Maia" <pmaia@austin.rr.com> wrote in message
news:n8pX8.99782$q53.2352660@twister.austin.rr.com...
> I appeal to the community for help... for I have failed...
>
> I have beaten my head against a wall trying to find the problem and
> have come up blank. I have an application that writes an Access
> database record about every 3-4 seconds. After running for several
> days I looked at Task Manager and noticed that it was consuming
> memory with every 3-4 records written (task manager only seems to
> have a 1-2k granularity). I have updated MDAC to 2.62 SP2 and
> Jet 4.0 Database to SP6 and the memory creep continues.
>
> I am fairly sure that it is something I am doing, but I am not familiar
> enough with the ADO API's to know the hidden secrets, yet. Any
> help would be greatly appreciated.
>
> The following code has the exception handling removed to simplify
> the post.With logging in each of the exception handlers, I have
> determined that there are no exceptions occurring.
>
> The code below is in a VC++ 6.0 (latest SP) DLL, that is called from
> C++ Builder.
>
> The DATABASE_HANDLE looks like...
>
> -----------------------------------------------------------
> typedef struct DATABASE_HANDLE
> {
> ADODB::_ConnectionPtr conRef;
> char databaseDSN[MAX_STRING];
> char userID[MAX_STRING];
> char password[MAX_STRING];
> long ADO_ErrorIdx;
> char *curErrMessage;
> } DATABASE_HANDLE;
> -----------------------------------------------------------
>
> I open the Database and leave it open (for weeks), writing the data to the
> database. Even if there was a leak in it, it would not (I hope) contribute
> to
> the leak that occurs on each addition to the database. Even though, if I
> close
> and re-open it, the previous creep level is the new starting point.
>
> But, for completeness, here is a snippet of the code to open the database:
>
> -----------------------------------------------------------
> // initialize the connection object
> dbHandle->conRef = NULL;
>
(void)dbHandle->conRef.CreateInstance(__uuidof(ADODB::Connection));
> // make sure it is opened read/write
> dbHandle->conRef->Mode = ADODB::adModeReadWrite;
> // (default)
> // only allow viewing of transactions, once they are committed
> dbHandle->conRef->IsolationLevel = ADODB::adXactCursorStability;
> // set the attributes, no attributes
> dbHandle->conRef->Attributes = 0;
> // save the DSN
> strncpy(dbHandle->databaseDSN, databaseDSN, MAX_STRING);
> // open the database
> (void)dbHandle->conRef->Open(databaseDSN, userID, password,
> ADODB::adConnectUnspecified);
>
> -----------------------------------------------------------
>
> -----------------------------------------------------------
> ADOWRITE_API BOOL ADO_AddNewRecordToDatabase(DATABASE_HANDLE *dbHandle,
> const char * const tableName, const char * const fields[],
> const char * const values[], int itemCount)
> {
> ADODB::_RecordsetPtr recRef = NULL;
> BOOL retCode = FALSE;
>
> // now add a record to the database
> if (dbHandle->conRef->State == (int)ADODB::adStateOpen)
> {
> int x;
> (void)recRef.CreateInstance(__uuidof(ADODB::Recordset));
> // since we are only adding records here,
> // a forward -only cursor would be the fastest
> recRef->CursorType = ADODB::adOpenForwardOnly;
> // open the recordSet
> (void)recRef->Open(tableName,
> _variant_t((IDispatch *)dbHandle->conRef, true),
> ADODB::adOpenKeyset, ADODB::adLockOptimistic,
> (int)ADODB::adCmdTable);
> // create a new data record
> (void)recRef->AddNew();
> // add the fields/values
> for (x = 0; x < itemCount; x++)
> {
> (void)recRef->Fields->GetItem(_variant_t(fields[x]))->
> put_Value(_variant_t(values[x]));
> }
> // update it to the database
> (void)recRef->Update();
> // it's there
> retCode = TRUE;
> // close the recordset
> (void)recRef->Close();
> // free the recordset
> recRef = NULL;
> }
> else
> { // add as a local message
> AddLogEntry("[ADO_AddNewRecordToDatabase] "
> "ConRef->State Does Not Show The Database Open");
> }
> // clear all errors
> (void)dbHandle->conRef->Errors->Clear();
> // return to caller
> return(retCode);
> }
> -----------------------------------------------------------
>
> Your consideration is greatly appreciated,
>
> Paul Maia
> paul_maia@hotmail.no^^spam.com
> remove no^^spam to reply
>
>
>
>
Technical Details
Message-ID:
<uv12UZaKCHA.2552@tkmsftngp08>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-08!supernews.com!newsfeed.online.be!newsfeed.wirehub.nl!newsfeed00.sul.t-online.de!t-online.de!tkmsftngp01!tkmsftngp08References:
<n8pX8.99782$q53.2352660@twister.austin.rr.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10845c,cc8cadb3e8b391c0 X-Google-Attributes: gid10845c,public X-Google-Thread: 10698b,cc8cadb3e8b391c0 X-Google-Attributes: gid10698b,public X-Google-Thread: f64f7,cc8cadb3e8b391c0 X-Google-Attributes: gidf64f7,public X-Google-Thread: 103747,cc8cadb3e8b391c0 X-Google-Attributes: gid103747,public X-Google-ArrivalTime: 2002-07-12 06:38:26 PST From: "Val Mazur" <group51a@hotmail.com> References: <n8pX8.99782$q53.2352660@twister.austin.rr.com> Subject: Re: ADO Memory Leak - Please Help Date: Fri, 12 Jul 2002 09:17:48 -0400 Lines: 140 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <uv12UZaKCHA.2552@tkmsftngp08> Newsgroups: comp.database.ms-access,microsoft.public.data.ado,microsoft.public.vc.database,borland.public.cppbuilder.database.ado NNTP-Posting-Host: 209.112.47.138 Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-08!supernews.com!newsfeed.online.be!newsfeed.wirehub.nl!newsfeed00.sul.t-online.de!t-online.de!tkmsftngp01!tkmsftngp08