ODBC Connection Problem

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

i use a ODBCConnection object in a multithread application.
Everytime the thread is running i create a new object of the ODBCConnection
and run my queries to fill my dataset. After that, i close the connection
and set it to nothing. But the application didn't free the memory of the
connection after the thread is shutdown.

I use Vb .NET 2003 & MaxDB 7.5 and MaxDB ODBCDriver 7.06
 
Hi Mario,

Try to use the Dispose() method after closing on your OdbcConnection and
OdbcCommand.

e.g.
Dim conn as OdbcConnection
Dim comm as OdbcCommand
...
conn.Close();
comm.Dispose();
conn.Dispose();

HTH
Christiaan
 
Hi Christiaan,

i have tryed it but there was no effect,
there were always remaining 8 - 80 kb in the memory of my application.

Also i have tried to call the GC at the end of my function, this has
no effect too.
 
Mario,

Could you send some code on how you instantiate objects and how you use ODBC
and ADO?
Maybe this will shed some light on the matter.

BTW: How do you call the GC? This is a proces you cannot control, unless you
mean releasing objects...

Cheers
Christiaan
 
Here is some code:


.... some init code ...

Dim prvConnection as OdbcConnection
prvConnection = New OdbcConnection(prvConnectionString)

Private DataAdapter As OdbcDataAdapter
DataAdapter = New OdbcDataAdapter("SELECT RFCTID FROM TIDMASTER Where State
='255' AND FUNCNAME='CONTROL_RECIPE_DOWNLOAD'", tidCon)
DataAdapter.Fill(newDS, "TIDMASTER")


.... some more SQL Statements ...

DataAdapter.Dispose()
prvConnection.Close()
prvConnection.Dispose()
prvconnection = Nothing

GC.Collect()
 
My ODBCDataAdapter has only the Dispose() Methode, when i type Dispose(true)
then VS 2003 marks it as an error.
 
Mario,

Which Framework version do you use?
The link I supplied to the msdn library states that it works (only) with
version 1.1

Christiaan
 
Mario,

Ignore my last post. I misread the entire msdn article.

Dispose(Boolean) is a protected method thats is called by Dispose() and
Finalize();

Dispose() will call Dispose(true)
Finalize() will call Dispose(false)

Sorry, about the confusion.

This means however, that I do not have a satisfying answer for your
question.
I will follow this post however, because you've got me intersted now....

Cheers
Christiaan
 
Mario,

Although that I said in the other newsgroup that you had more change here,
do I not see much answers, which go further than dispose. What will not help
you. because dispose of a connection does not free memory.

The way you have created that connection makes if it will be released.
However, as well is memory in a managed situation something that is hard to
manage by yourself, while by instance the Task Manager is mostly giving
wrong information about that.

I like it to point in this kind of cases to show people some replies Willie
has made mainly in the general newsgroup (again another one so if you want
to get contact with Willy go to that) an obvious way to let him react is
placing in your subject "The taskmanager is giving wrong information about
memory"

Don't be afraid, if you do it, and I see it, than I will tell to him that I
wrote that.

:-)

Here some messages I have searched for that, maybe better that you read that
in advance before you place direct a message.

http://groups.google.com/group/micr...lly+memory&qt_g=1&searchnow=Search+this+group

I hope this gives some more help than my previous.

Cor
 
Thank you for your helping,

i have used the System.Diagnostics.Process.GetCurrentProcess.WorkingSet()
method to utilize the memoryusage of the process.

I have created a workaround myself because i think it's a problem with
the ODBC Driver from MaxDB. The same function running on a Microsoft Access
DB was not making the same problem. So i have created a global pool of
connections objects in the class constructor and then i use this Pool of
ODBC Connections to get my results from the DB. It's work fine only the
creating of the
object will use some more processing time.

best regards

Mario
time.
 
Back
Top