I'm an ASP developer positioning myself to move to ASP.NET. Most of

the framework is nicely self documenting, but I've run into a couple

of confusing issues that probably are straightforward to someone

coming from an application design background, but over a year of

solid asp/vbscript work has dulled my OOP instincts somewhat.



In regards to closing connections, I have found many contradictory

examples that probably all "work" due to the default destructor and

the fact that garbage collection is happening behind the scenes, but

what is the correct course to follow in regards to closing

connections, dataadapters, and the like?



Generally speaking, most of the examples I have seen from outside

sources explicitly close the datareader and the connection objects

when all they do is manually loop through the datareader with

datareader.read(). However, when they use databinding to bind the

datareader to a grid, these close() calls are not made. Also, when

dataadapters and datasets are used, I generally don't see any close

calls made. Occasionally, I see something like the following (quoted

from beginning asp.net with vb.net)



...

dgEmps.DataSource = objCommand.ExecuteReader

(CommandBehavior.CloseConnection)

dgEmps.DataBind()

End Sub



It is my understanding that passing CommandBehavior.CloseConnection causes

the connection to be closed when the reader is closed. However, what

is the point of doing this if the reader is never explicitly closed?

If you're going to rely on the garbage collector and destructor to

take care of closing the connections, why bother linking the

connections connection status to that of the reader? If the default

destructor of the reader will close the connection, why won't the

default destructor of a connection do the same?



In short, most of the data connection oriented classes have close

methods. Is there a good rule of thumb to know when to explicitly

call them and when not to? Generally the microsoft documentation

*always* explicitly calls close, but not a lot of the third party

docs/samples do.



Also, if you do something like the following: (with an already

populated dataset)



...

dim objEmps as DataTable

objEmps = objDataSet.Tables("Employees")

objDataSet = Nothing

...

You can continue using objEmps like nothing happened. Is the default

behavior in this sort of situation to make a fully copy of the

object, instead of acting like a pointer? Is there any documention

in the SDK or online that I can refer to to see the rules of this

sort of situation? It seems a waste or resources to me to make a

copy of that table just to make working with it easier.



It's my instinct to try to do an operation such as:



objTable = objDataSet.Tables("Employees")

objNewRow = objTable.NewRow()

objNewRow.Item("FirstName") = "Norman"

objNewRow.Item("LastName") = "Blake"

objTable.Rows.Add(objNewRow)

dgNameList2.DataSource = objTable.DefaultView

dgNameList2.DataBind()



in a manner such as



objNewRow = objDataSet.Tables("Employees")

objNewRow.Item("FirstName") = "Norman"

objNewRow.Item("LastName") = "Blake"

objTable.Rows.Add(objNewRow)

dgNameList2.DataSource = objTable.DefaultView

dgNameList2.DataBind()



But this doesn't seem possible. Are there any resources/explanations

available online or elsewhere that I could refer to for coding

style/technique pointers to make this transition easier, in either

of the two issues I mentioned above?