*I posted this on the aspx_beginners list, but nobody answered, even

to just say "Huh?" so I'm reposting it here in hopes that someone

might provide an answer. I apologize in advance if this violates any

manner of community rule regarding crossposting*



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?  



-- 

Best regards,

 Jay                          mailto:joliver@n...

some quick comments on your note:



1 - ADO.NET datasets are roughly the same as disconnected recordsets for

ADO. they are *always* disconnected.  In fact the Fill method of a command

object will acutally do the following:



open the associated connection

execute the command

close the associated connection



that's why you can continue to 'party' on the dataset after you destroy the

command and connection objects.



2 - ADO.NET datareaders are roughly the same as the read-only firehose

cursor for ADO. they are *always* connected until you explictly close them.

That is why you just explicitly use OPEN, READ, and CLOSE with them. To make

it possible to return datareaders from a component, MSFT added the

CommandBehvior stuff. This tells the runtime to go ahead and close the

connection when the reader is drained. it happens behind the scenes, so

there's no need to call CLOSE in that case.



Finally, since you're dealing with ASP.NET, each page creates and destroys

the object tree on each refresh. the actual destructors will fire at the end

of each page delivery and you don't need to sweat this much at all.  It

would be different if you were doing a stateful windws app, but that is not

the case here.



hope this helps.



MCA



-----Original Message-----

From: Jay Oliver [mailto:joliver@n...]

Sent: Thursday, December 06, 2001 9:41 AM

To: ASP+

Subject: [aspx] ado.net / basic .net questions





*I posted this on the aspx_beginners list, but nobody answered, even

to just say "Huh?" so I'm reposting it here in hopes that someone

might provide an answer. I apologize in advance if this violates any

manner of community rule regarding crossposting*



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?



--

Best regards,

 Jay                          mailto:joliver@n...

That is a pretty long question.  So, I will just give you some things

that I have observed.



When using the DataReader, If you do not close the connection it stays

around for a while.  I was having problems with a SQL script running and

it was caused by four connections (I ran my app four times) created for

my DataReader.  So, I am now in the habit of using connection.close()

for DataReaders.



DataAdapters on the other hand seem to do a good job of closing

connections, but it is still probably not a bad idea to close those

resources.



Last thing, you can not count on the garbage collector to clean up

objects(and there associated connections) right away.  The garbage

collector runs when it has a chance, so a number of classes have a close

method.  The close method is meant to be called to clean up any

resources.  From what I have read, this is Microsofts preference.



Hope that helps.  I am sure we will hear a lot more discussion on best

practices.



Dave



-----Original Message-----

From: Jay Oliver [mailto:joliver@n...]

Sent: Thursday, December 06, 2001 6:41 AM

To: ASP+

Subject: [aspx] ado.net / basic .net questions





*I posted this on the aspx_beginners list, but nobody answered, even

to just say "Huh?" so I'm reposting it here in hopes that someone

might provide an answer. I apologize in advance if this violates any

manner of community rule regarding crossposting*



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 =3D 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 =3D objDataSet.Tables("Employees")

objDataSet =3D 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 =3D objDataSet.Tables("Employees")

objNewRow =3D objTable.NewRow()

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

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

objTable.Rows.Add(objNewRow)

dgNameList2.DataSource =3D objTable.DefaultView

dgNameList2.DataBind()



in a manner such as



objNewRow =3D objDataSet.Tables("Employees")

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

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

objTable.Rows.Add(objNewRow)

dgNameList2.DataSource =3D 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? 



--

Best regards,

 Jay                          mailto:joliver@n...