Quick OOP question - object lifetime

I've written a SQL Query class so that I can get query results in as few lines as possible throughout my application.
My Query class has a DataTable property (called Results) so I can access the returned rowset after the query is executed in the New(SQLString as String) method.
I've given it a load of 'Implements IDisposable' boilerplate I found online - so that I can use 'Using.. End Using' and all seems well. It's working.

Can I just ask for a quick confirmation ( I think I'm getting the hang of OOP, but want to make sure) ... given the following code...

Code:

---

        Dim copyDt As New DataTable
        Using test1 As New SQLstuff.Query("SELECT * from MyTable")
            MsgBox(test1.RowCount & "  " & test1.Results.Columns(0).ColumnName)
            copyDt = test1.Results  ' both are DataTable object instances
        End Using
        MsgBox(copyDt.Rows.Count & "  " & copyDt.Columns(0).ColumnName)

---

The two MsgBoxes give the same results.

Q) Does copyDt end up referencing the same object instance in memory as the original test1.results, and it persists after the 'Using.. End Using' block, even when test1 no longer exists, purely because the GC knows that copyDt is also pointing to the same data, and the whole lot will be GCollected and cleared after copyDt falls out of scope?

(Optional second Question - I've run a query within a FOR loop for thousands of times (impressively quick!) and in Task Manager the amount of memory used by VB stays around the same, is that a valid way to check for memory leaks?)

Thanks

Quote:

---

Originally Posted by geek648

Q) Does copyDt end up referencing the same object instance in memory as the original test1.results, and it persists after the 'Using.. End Using' block, even when test1 no longer exists, purely because the GC knows that copyDt is also pointing to the same data, and the whole lot will be GCollected and cleared after copyDt falls out of scope?
Thanks

---

Yes, copyDt is the exact same object as test1.results. Also, disposing of an object does not invoke the GC to clean it up. Dispose is actually provided as a way for you clean up unmanaged resources as the GC cannot clean them up. You must implement IDisposable if your class uses unmanaged resources otherwise you would have memory leaks in any app that uses your class.

Watching the memory is not a totally reliable way to check for leaks (or leeks, if you are vegetarian). The fact that the memory usage isn't going up is certainly a good sign, but if the memory WAS going up, that wouldn't necessarily mean that you are leaking memory. The app is liable to request more memory from the OS before it attempts to clean up what it has, and if the OS has plenty of memory, it is liable to comply with the request without forcing the app to clean house. Therefore, an increase in memory could just be an indication that the two (the app and the OS) have opted for the cheaper route of adding memory rather than the more expensive route of recovering fragmented memory blocks already allocated.

So: Constant memory = Good, but Increasing memory does not = Bad....in all cases.

Thanks, it all seems to be behaving itself. Just 4 lines of code (including the End Using) gets me a SQL query result loaded into a datagridview, so I'm happy with my first real class :)

My query method uses SqlConnection, SqlCommand and SqlAdaptor in 3 nested Usings, so I'm hopeful that everything is being cleaned up and won't come back to haunt me farther down the line!

It should be fine. I do pretty much the same thing in many places.