challenge-group
New Member
I'm an ASP developer positioning myself to move to ASP.NET. Most of<BR> the framework is nicely self documenting, but I've run into a couple<BR> of confusing issues that probably are straightforward to someone<BR> coming from an application design background, but over a year of<BR> solid asp/vbscript work has dulled my OOP instincts somewhat.<BR><BR> In regards to closing connections, I have found many contradictory<BR> examples that probably all "work" due to the default destructor and<BR> the fact that garbage collection is happening behind the scenes, but<BR> what is the correct course to follow in regards to closing<BR> connections, dataadapters, and the like?<BR><BR> Generally speaking, most of the examples I have seen from outside<BR> sources explicitly close the datareader and the connection objects<BR> when all they do is manually loop through the datareader with<BR> datareader.read(). However, when they use databinding to bind the<BR> datareader to a grid, these close() calls are not made. Also, when<BR> dataadapters and datasets are used, I generally don't see any close<BR> calls made. Occasionally, I see something like the following (quoted<BR> from beginning asp.net with vb.net)<BR><BR> ...<BR> dgEmps.DataSource = objCommand.ExecuteReader(CommandBehavior.CloseConn ection)<BR> dgEmps.DataBind()<BR>End Sub<BR><BR> It is my understanding that CommandBehavior.CloseConnection causes<BR> the connection to be closed when the reader is closed. However, what<BR> is the point of doing this if the reader is never explicitly closed?<BR> If you're going to rely on the garbage collector and destructor to<BR> take care of closing the connections, why bother linking the<BR> connections connection status to that of the reader? If the default<BR> destructor of the reader will close the connection, why won't the<BR> default destructor of a connection do the same?<BR><BR> In short, most of the data connection oriented classes have close<BR> methods. Is there a good rule of thumb to know when to explicitly<BR> call them and when not to? Generally the microsoft documentation<BR> *always* explicitly calls close, but not a lot of the third party<BR> docs/samples do.<BR><BR> Also, if you do something like the following: (with an already<BR> populated dataset)<BR><BR> ...<BR> dim objEmps as DataTable<BR> objEmps = objDataSet.Tables("Employees")<BR> objDataSet = Nothing<BR> ...<BR> You can continue using objEmps like nothing happened. Is the default<BR> behavior in this sort of situation to make a fully copy of the<BR> object, instead of acting like a pointer? Is there any documention<BR> in the SDK or online that I can refer to to see the rules of this<BR> sort of situation? It seems a waste or resources to me to make a<BR> copy of that table just to make working with it easier.<BR><BR> It's my instinct to try to an operation such as:<BR><BR> objTable = objDataSet.Tables("Employees")<BR> objNewRow = objTable.NewRow()<BR> objNewRow.Item("FirstName") = "Norman"<BR> objNewRow.Item("LastName") = "Blake"<BR> objTable.Rows.Add(objNewRow)<BR> dgNameList2.DataSource = objTable.DefaultView<BR> dgNameList2.DataBind()<BR><BR> in a manner such as<BR><BR> objNewRow = objDataSet.Tables("Employees")<BR> objNewRow.Item("FirstName") = "Norman"<BR> objNewRow.Item("LastName") = "Blake"<BR> objTable.Rows.Add(objNewRow)<BR> dgNameList2.DataSource = objTable.DefaultView<BR> dgNameList2.DataBind()<BR><BR> But this doesn't seem possible. Are there any resources/explanations<BR> available online or elsewhere that I could refer to for coding<BR> style/technique pointers to make this transition easier, in either<BR> of the two issues I mentioned above?