.net - Is this a memory leak? Pls check code below -

in vb application use datasets follows:

dim rs dataset dim sql string = "some sql" rs = getdataset(sql, db) ' work data  sql = "another sql" rs = getdataset(sql, db) ' more code  rs.dispose 

will cause memory leak if add dispose @ end of sub or should dispose rs after every usage of it?

well, problem "memory leaks" in .net not same in languages direct memory management (like c/c++). in .net leaked memory result of referencing object 1 of garbage collector roots caused badly managed dependencies between object in graph, not missing memory deallocation.

technically, there nothing wrong not disposing disposable object , application can work quite not calling dispose @ all.

while have few nice examples of .net memory leaks in article, http://alexatnet.com/articles/memory-leaks-in-net-applications, missing 1 trivial example - missing dispose in case when object data consists of 2 parts - tiny managed wrapper around massive array of unmanaged data (in other words, images). imagine application creates several images , not dispose them when no longer required. in case gc not collect garbage , destroy images gc threshold not being hit , images consume available virtual memory , crash application.

consider opposite - quite large .net object , tiny unmanaged resource small com object. in case if disposed not called explicitly, intensive use of these object call gc enough clean objects not disposed manually , never have outofmemory exception.

this why hard tell if code example contains "memory leak" or, more precise, cause troubles?

the example not accurate , quite clear first object not disposed. if consists of managed objects, not cause troubles - code not good. if has significant amount of unmanaged data (blobs or something) may crash application.

so if want sure, rewrite "using" http://msdn.microsoft.com/en-gb/library/htd05whh.aspx. if exreme , consider life being plain without working late debugging outofmemory issues - keep is.

sorry long answer such simple question.