G
Guest
does the cmd.ExecuteScalar() auto close the connection the same as
RxecuteReader(commandbehavior.CloseConnection)?
RxecuteReader(commandbehavior.CloseConnection)?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Marina
It does not have such an overload. You have to close the connection
manually.
manually.
S
Sahil Malik [MVP]
No it doesn't.
W
William \(Bill\) Vaughn
No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Sahil Malik said:No it doesn't.
--
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
-------------------------------------------------------------------------------------------
G
Guest
it does seem strange that it's not available.
thanks for your reply!
--
thanks (as always)
some day i''m gona pay this forum back for all the help i''m getting
kes
thanks for your reply!
--
thanks (as always)
some day i''m gona pay this forum back for all the help i''m getting
kes
William (Bill) Vaughn said:No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
S
Sahil Malik [MVP]
Why "it should"?
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------
William (Bill) Vaughn said:No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
G
Guest
there's a lot i don't know concerning ado.net, so please show me how to do
this.
why is there one for a datareader
i'm returning datareaders via functions and the
commandbehavior.closeconnection
means i can use RETURN cmd.executereader(commandbehavior.closeconnection)
i can't do the same with executescaler. I'm setting a variable, closing the
connection and returning the variable.
thanks
kes
--
thanks (as always)
some day i''m gona pay this forum back for all the help i''m getting
kes
this.
why is there one for a datareader
i'm returning datareaders via functions and the
commandbehavior.closeconnection
means i can use RETURN cmd.executereader(commandbehavior.closeconnection)
i can't do the same with executescaler. I'm setting a variable, closing the
connection and returning the variable.
thanks
kes
--
thanks (as always)
some day i''m gona pay this forum back for all the help i''m getting
kes
S
Sahil Malik [MVP]
Kes,
Here is a very common scenario where you DON"T want the connection to close
(even the logical connection, not the pooled physical connection).
Say you have a hierarchical dataset taht you are trying to save. DataAdapter
cannot do that job for you, you have to resort to your commands. In that
circumstance, you want a number of Command.ExecuteScalar, or NonQuery to
execute, and stay on the same transaction.
In that circumstance it makes sense that the connection not be closed,
because you need to stick with the same underlying physical connection (so
you can keep a hold of it).
Secondly, all Command.Execute* expect an open connection. Why should
ExecuteScalar be non-standard?
Now if you'd argue that there should be a non default overload that accepts
a parameter, that makes it work like a DataAdapter.Fill operation - I can
probably agree to that, but you can easily emulate that in your Data Layer
anyway.
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
Here is a very common scenario where you DON"T want the connection to close
(even the logical connection, not the pooled physical connection).
Say you have a hierarchical dataset taht you are trying to save. DataAdapter
cannot do that job for you, you have to resort to your commands. In that
circumstance, you want a number of Command.ExecuteScalar, or NonQuery to
execute, and stay on the same transaction.
In that circumstance it makes sense that the connection not be closed,
because you need to stick with the same underlying physical connection (so
you can keep a hold of it).
Secondly, all Command.Execute* expect an open connection. Why should
ExecuteScalar be non-standard?
Now if you'd argue that there should be a non default overload that accepts
a parameter, that makes it work like a DataAdapter.Fill operation - I can
probably agree to that, but you can easily emulate that in your Data Layer
anyway.
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
M
Miha Markic [MVP C#]
I am also curious. Why it should?
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
William (Bill) Vaughn said:No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
W
William \(Bill\) Vaughn
Oh, I can't think of more than these reasons:
1) Connections are a precious resource. Getting them closed quickly
(when they can be) is good for scalability
2) Consistency. All of the Command execute functions that require open
connections should have a CommandBehavior.CloseConnection available.
3) Too many folks complain about overflowing connection pools look to
the ExecuteReader as the cause--it could be elsewhere. Setting CBCC makes it
easier to manage connections.
Just because the enumeration is there does not mean you have to set it.
There are valid reasons not to close the connection (as you expect to use it
again in the same function or you're working with a transaction...)
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
1) Connections are a precious resource. Getting them closed quickly
(when they can be) is good for scalability
2) Consistency. All of the Command execute functions that require open
connections should have a CommandBehavior.CloseConnection available.
3) Too many folks complain about overflowing connection pools look to
the ExecuteReader as the cause--it could be elsewhere. Setting CBCC makes it
easier to manage connections.
Just because the enumeration is there does not mean you have to set it.
There are valid reasons not to close the connection (as you expect to use it
again in the same function or you're working with a transaction...)
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Miha Markic said:I am also curious. Why it should?
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
William (Bill) Vaughn said:No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
M
Miha Markic [MVP C#]
Hi,
Point 1. and 3.: Perhaps, but better practise is to use a try/finally (or
C#'s using) block to open and close the connection. Furthermore, you
normally do more than just one operation when connection is open so it won't
help much.
Personally I don't need them as I am always explicitely opening and closing
connections.
Sure. I just think that nothing beats explicit open and close and nothing
won't protect you from forgetting to close it even if that parameter exists.
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
William (Bill) Vaughn said:Oh, I can't think of more than these reasons:
1) Connections are a precious resource. Getting them closed quickly
(when they can be) is good for scalability
Point 1. and 3.: Perhaps, but better practise is to use a try/finally (or
C#'s using) block to open and close the connection. Furthermore, you
normally do more than just one operation when connection is open so it won't
help much.
2) Consistency. All of the Command execute functions that require open
connections should have a CommandBehavior.CloseConnection available.
Personally I don't need them as I am always explicitely opening and closing
connections.
3) Too many folks complain about overflowing connection pools look to
the ExecuteReader as the cause--it could be elsewhere. Setting CBCC makes
it easier to manage connections.
Just because the enumeration is there does not mean you have to set it.
Right.
There are valid reasons not to close the connection (as you expect to use
it again in the same function or you're working with a transaction...)
Sure. I just think that nothing beats explicit open and close and nothing
won't protect you from forgetting to close it even if that parameter exists.
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Miha Markic said:I am also curious. Why it should?
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
William (Bill) Vaughn said:No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
No it doesn't.
--
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
W
William \(Bill\) Vaughn
I agree, Using is very handy for local instantiation/tear-down (even in
VB.NET 2.0).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
VB.NET 2.0).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
Miha Markic said:Hi,
William (Bill) Vaughn said:Oh, I can't think of more than these reasons:
1) Connections are a precious resource. Getting them closed quickly
(when they can be) is good for scalability
Point 1. and 3.: Perhaps, but better practise is to use a try/finally (or
C#'s using) block to open and close the connection. Furthermore, you
normally do more than just one operation when connection is open so it
won't help much.
2) Consistency. All of the Command execute functions that require open
connections should have a CommandBehavior.CloseConnection available.
Personally I don't need them as I am always explicitely opening and
closing connections.
3) Too many folks complain about overflowing connection pools look to
the ExecuteReader as the cause--it could be elsewhere. Setting CBCC makes
it easier to manage connections.
Just because the enumeration is there does not mean you have to set it.
Right.
There are valid reasons not to close the connection (as you expect to use
it again in the same function or you're working with a transaction...)
Sure. I just think that nothing beats explicit open and close and nothing
won't protect you from forgetting to close it even if that parameter
exists.
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
Miha Markic said:I am also curious. Why it should?
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info
No it doesn't and it SHOULD (IMHO).
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________
No it doesn't.
--
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx