the difference between SqlConnection.IDisposable.Dispose() and SqlConnection.Dispose()
jinfen...@msn.com
SqlConnection.IDisposable.Dispose() and SqlConnection.Dispose(). Both
of them realize the function of releasing the connection to the
ConnectionPool? Do they have the same effection source code? If they
are different, who can tell me the differences? If they are same, why
MS gives the SqlConnection.IDisposable.Dispose, but only
SqlConnection.Dispose() method?
In the MSDN, there are following description about the
SqlConnection.IDisposable.Dispose Method:
"This member supports the .NET Framework infrastructure and is not
intended to be used directly from your code." what's the meaning of
it?
If the user has called the SqlConnection.IDisposable.Dispose() in the
client application, what probem results in? and if there are some
problem becomes, then why did MS give us such a method?
in the same, who can tell me the using of
"SqlConnection.ICloneable.Clone ",
"SqlConnection.IDbConnection.BeginTransaction" and
"SqlConnection.IDbConnection.CreateCommand"?
Anybody can help me to solve my question? thanks a lot.
![Cor Ligthert [MVP]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Cor Ligthert [MVP]
Both of them are removing the connectionstring from the connectionobject.
They both have nothing to do direct with the ConnectionPool, although you
should close a connection either by close or dispose to let the
ConnectionPool do its job.
Every Interface can be used to get its members (in the implementing
contract) from the implementing class. Therefore it is an interface. A good
programmer start the name of his interfaces all with a capital I.
I hope that this gives an idea
Cor
Frans Bouma [C# MVP]
what does 'SqlConnection.IDisposable.Dispose' mean? 'IDisposable'
isn't a property or something of SqlConnection. 'Dispose()' is a method
in Component, the base class of SqlConnection. SqlConnection overrides
Dispose(true), which is called from Dispose(), and therefore whatever
Dispose() you call, it doesnt matter.
FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
jinfen...@msn.com
please read the following URL and look at the left frame:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemDataSqlClientSqlConnectionMethodsTopic.asp
there are two methods in the SQLConnection:
"Dispose" and "SqlConnection.IDisposable.Dispose" Method.
and in MSDN , the description about the
"SqlConnection.IDisposable.Dispose" is: "This member supports the .NET
Framework infrastructure and is not intended to be used directly from
your code".
can you help to tell me, what's the meaning of the above setence? MS
advice me that i should not call the
"SqlConnection.IDisposable.Dispose", yeah?
if there is a client code, like this (copied from MSDN, and i have
modified it):
public void ReadMyData()
{
String myConnString = "Persist Security Info=False;User
ID=sa;Initial Catalog=Northwind;Data Source=DTK-S-SVR;User
ID=sa;Pwd=sa";
string mySelectQuery = "SELECT OrderID, CustomerID FROM Orders";
SqlConnection myConnection = new SqlConnection(myConnString);
SqlCommand myCommand = new SqlCommand(mySelectQuery,myConnection);
myConnection.Open();
SqlDataReader myReader;
myReader = myCommand.ExecuteReader();
while (myReader.Read())
{
Console.WriteLine(myReader.GetInt32(0) + ", " +
myReader.GetString(1));
}
myReader.Close();
//myConnection.Close(); // old source code.
IDisposable disposable =myConnection as IDisposable; // new
source code.
disposable.Dispose(); // new source code.
}
will it cause some problem when cast the myConnection to IDisposable
and call disposable.Dispose() ?
Does the "new souce code" have the same effect as the "old source code"
??
if they are, why MS implements the method of "IDisposable.Dispose()"
explicity. I means: there is only the SqlConnection.Dispose() method.
if there is no problem here, then can you why MS said that "This member
supports the .NET Framework infrastructure and is not intended to be
used directly from your code."??
if there is some problem, then why MS does not make the methods of
SqlConnection.IDisposable.Dispose() and SqlConnection.Dispose()
shared the same source code? and why MS tell us that there exists a
"SqlConnection.IDisposable.Dispose()" method, but warn us not to
call it??
in the same, how about the "SqlConnection.ICloneable.Clone ",
"SqlConnection.IDbConnection.BeginTransaction" and
"SqlConnection.IDbConnection.CreateCommand"?
i do not whether you have understand my question for my poor english
and expression.
can you help me? anyway, thanks to all of you.
jinfen...@msn.com
SQLConnection. please read my answer to Cor.
'SqlConnection.IDisposable.Dispose' is copied from MSDN. :-)
I think it means that SQLConnection has implemnt the Dispose() method
of the IDisposable explicity.
I want to know the difference between the two method of
SqlConnection.IDisposable.Dispose() and SqlConnection.Dispose().
Thanks to you!!! thanks!
Cor Ligthert [MVP]
Both Frans and me are not first language English speakers (AFAIK is Frans
born where the native language is Fries and I where it is Dutch). In my
opinion should you never excuse you for your English in these newsgroups.
Almost everybody, no matter how good he can speak a language, will make
errors in email messages (even in his own). I assume that you are using the
English version of Visual Studio so that tells enough.
I thought that the protected dispose is used by component (don't mix this up
with the rest from what I write about component). If you open a form or a
component (by the designer), than you see the implementation of IDisposable
direct. That part is used to do the most of the disposing.
Nice pages about Idisposable are these new ones
As I said, be aware that if you use a form or a component the code is
already in the designer created part.
However as long discussions has be done in this newsgroup. Disposing and
Closing have the same effect on the connection pool.
I hope this gives some information.
Cor
Frans Bouma [C# MVP]
> FB, i know that 'IDisposable' is not one property of the
> SQLConnection. please read my answer to Cor.
> 'SqlConnection.IDisposable.Dispose' is copied from MSDN. :-)
> I think it means that SQLConnection has implemnt the Dispose() method
> of the IDisposable explicity.
I thought that it meant that, but checking SqlConnection in reflector
I couldn't find IDisposable explicit implementations :D Hence my
question :)
> I want to know the difference between the two method of
> SqlConnection.IDisposable.Disp限ose() and SqlConnection.Dispose().
I have no idea.
William (Bill) Vaughn
Framework code to see what it does. You must have a lot more time on your
hands that we do.
Frankly, it does not matter what they do. You don't need to call
them--either of them. As long as you use Close on the Connection you're
fine. Sure, you can call Dispose if you want to, but it won't help the
problem you're trying to solve.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
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.
__________________________________
"Frans Bouma [C# MVP]" <perseus.us...@xs4all.nl> wrote in message
news:xn0ehgc5...@news.microsoft.com...
Frans Bouma [C# MVP]
> Ok... if you're that curious, use Reflector to walk through the .Net
> Framework code to see what it does. You must have a lot more time on
> your hands that we do.
>
> Frankly, it does not matter what they do. You don't need to call
> them--either of them. As long as you use Close on the Connection
> you're fine. Sure, you can call Dispose if you want to, but it won't
> help the problem you're trying to solve.
On a side note: not all ADO.NET providers' connection objects can
live without a Dispose call. For example the Firebird .NET provider and
the ODP.NET providers do need a call to Dispose to properly clean up.
(especially firebird, for cleaning up on the server side!).
FB, who still couldn't find an explicit IDisposable implementation on
SqlConnection...
jinfen...@msn.com
If i was just a client programmer, i think all the information from you
and MSDN is enough.
but,... now i am trying to develop one new .NET Data Provider for own
database.
so i want to know what has happened in SQL .NET Data Provider.
it give me a dozens of puzzling interface.
here is "SqlConnection.IDisposable.Dispose() " and
"SqlConnection.Dispose()".
In fact, the SQLConnection is inherited from Compnent, which has
implemented the IDisposable.
This is very like the question of "deadly diamond", that one Class
inherits one Interface from TWO path.
IDisposable
/ \
| |
Component IDBConnection
| |
\ /
SQLConnection
if there is no difference between the
SqlConnection.IDisposable.Dispose() and SqlConnection.Dispose(),
then MS has no need to implement the
SqlConnection.IDisposable.Dispose() explicitly. But, it has done
it, that means there are some differences between them. What's that?
MSDN has not told us, it just warn us not to call the
SqlConnection.IDisposable.Dispose() in the client program. :(
In the Oracle® Data Provider for .NET,
public sealed class OracleConnection : Component, IDbConnection,
ICloneable
but, OracleConnection has not implement the
IDbConnection.IDisposable.Disposable() explicity.
MS, :-(
jinfen...@msn.com
copied from Reflector:
System.Data.SqlClient.SqlConnection.System.Data.IDbConnection.BeginTransaction()
: IDbTransaction
IDbTransaction IDbConnection.BeginTransaction()
{
return this.BeginTransaction();
}
I think that the disposable is same as here .
but, but why MS does such a foolish action :-(
this folliwing is copied from MSDN in the
SqlConnection.IDbConnection.BeginTransaction Method ():
"This member supports the .NET Framework infrastructure and is not
intended to be used directly from your code."
faint to death. ~
Frans Bouma [C# MVP]
> If i was just a client programmer, i think all the information from
> you and MSDN is enough.
> but,... now i am trying to develop one new .NET Data Provider for
> own database.
there are guidelines for that if I'm not mistaken. And I think you
should relax a little. I work with a lot of ADO.NET providers and none
of them works the same as the others. So 'what should be done' is what
you think is the easiest for your users :).
So, 'Close()' should clean up, and for example connection.Dispose()
should also dispose commands, parameters etc.
In general derive a class from DbConnection, and override the specific
methods to add your own code.
> so i want to know what has happened in SQL .NET Data Provider.
> it give me a dozens of puzzling interface.
> here is "SqlConnection.IDisposable.Dispose() " and
> "SqlConnection.Dispose()".
Have you looked into the code with reflector ? I think you should do
that. :)
> In fact, the SQLConnection is inherited from Compnent, which has
> implemented the IDisposable.
> This is very like the question of "deadly diamond", that one Class
> inherits one Interface from TWO path.
> IDisposable
> / \
> | |
> Component IDBConnection
> | |
> \ /
> SQLConnection
>
> if there is no difference between the
> SqlConnection.IDisposable.Dispose() and SqlConnection.Dispose(),
> then MS has no need to implement the
> SqlConnection.IDisposable.Dispose() explicitly. But, it has done
> it, that means there are some differences between them. What's that?
> MSDN has not told us, it just warn us not to call the
> SqlConnection.IDisposable.Dispose() in the client program. :(
I looked up the page, and I can only get to that page through the
index. So I think it's a mistake in the MSDN. As said by others in this
thread, look at the code through reflector first, then come back here
with questions.
Also, inherited interfaces are simply type definitions, not
implementations. So 1 routine can serve the Dispose() method of
multiple interfaces.
> In the Oracle® Data Provider for .NET,
> public sealed class OracleConnection : Component, IDbConnection,
> ICloneable
> but, OracleConnection has not implement the
> IDbConnection.IDisposable.Disposable() explicity.
>
> MS, :-(
Neither has sqlconnection!!! Look into the code! Just because it's an
error in the MSDN doesn't mean it's true. Why do you ignore what we
said and keep believing an errorous page in the msdn?
FB
Frans Bouma [C# MVP]
> :-)
>
>
> copied from Reflector:
>
> System.Data.SqlClient.SqlConnection.System.Data.IDbConnection.BeginTra
> nsaction() : IDbTransaction
> IDbTransaction IDbConnection.BeginTransaction()
> {
> return this.BeginTransaction();
> }
>
> I think that the disposable is same as here .
> but, but why MS does such a foolish action :-(
>
> this folliwing is copied from MSDN in the
> SqlConnection.IDbConnection.BeginTransaction Method ():
> "This member supports the .NET Framework infrastructure and is not
> intended to be used directly from your code."
> faint to death. ~
They say that because IdbConnection.BeginTransaction() might be
changed later, in future versions, you should use
SqlConnection.BeginTransaction().
It's not foolish, it's common sense.
jinfen...@msn.com
i have know the reason. :-(
jinfen...@msn.com
MSDN Error？
why the MS make such an Error .
I have said that now i am developing one .NET Data Provider for my own
database, so i should know the everything what have happened in the SQL
.NET Data Provider, and learning something from the MS's code.
now i have realized why MS give us such a SQL .NET Data Provider.
wait a minute, and i will write it clearly.
jinfen...@msn.com
///--------------
public interface myInterface
{
Object getobject();
}
public class MyImplement : myInterface
{
public String getobject() //override.
{
return "str";
}
}///---------------
the code above can not be compiled, the compiler will have give us an
error. Because the method of MyImplement.getobject() has a wrong
return type, which is "String", but the method of
MyInterface.getobject() declared that the return type is "Object:. Here
the compiler take the "return type" into the "override" compile
progregess. If MyImplement.getobject() returns "String", this is not
the implementation of MyInterface.getobject().
now let's take a look at another code.
///---------------
public class AnotherImplement
{
public object getobject()
{
return new object();
}
public string getobject() //overload
{
return new string("");
}
}
///---------------
Here I want to overload the method of "getobject()", but the compiler
give us an error. Here the compiler DOES NOT take the "return type"
into the "overload" compile progregess (DIFFERENCE WITH THE OVERRIDE).
Now let's go back to the IDBConnection and SQLConnection.
In the interface of IDbConnection, it declares one method of
"createcomand".
///----------
IDbConnection {
....
IDbCommand CreateCommand();
....
}
///----------
When design the interface of IDBConnection, the designer does not
what's kind of "Command" will be returned, for example
"SQLCommand","OracleCommand". so in the IDbConnection.CreateCommand(),
it only return an interface of "IDbCommand".
Now we are design the SQLConnection which implements the interface of
"IDbConnection". if in the SQLConnection, it only write :
///---------
SQLConnection:IDbConnection {
....
SQLCommand CreateCommand() {
........
}
....
}
///---------
the compiler will give us an error, because the "return type" is
SQLCommand, but not IDbCommand(defined in the IDbConnection). THE
COMPILER TAKE THE RETURN TYPE INTO THE COMPILE PROGRESS. so we must
give another definition of "IDbConnection.CreateCommand()".
if we write the code as follows:
///---------
SQLConnection:IDbConnection {
....
SQLCommand CreateCommand() {
........
}
IDBCommand CreateCommand() {
.......
}
....
}
///---------
The compiler will give us an error. THE COMPILER DOES NOT TAKE THE
RETURN TYPE INTO THE COMPILE PROGRESS.
so the SQLConnection have to implement the
IDbConncection.CreateCommand explicyly.
///--------
SQLConnection:IDbConnection {
....
SQLCommand CreateCommand() {
........
}
IDBCommand IDbConnection.CreateCommand() {
return this.CreateCommand();
}
....
}
///---------
The above is the SQLConnection.
============BUT============
The MSDN told us the "we should call the
SQLConnection.IDbConnection.CreateCommand() in the client program".
that is, "we should use the SQLConnection.CreateCommand() in the client
program."
THIS will result a foolish result. In the client pogram, we will write
such a code:
///------------
void doSomething() {
SqlConnection conn = new SqlConnection(connectionString);
SqlCommand command = conn.CreateCommand();
// We MUST have call
SqlConnection.CreateCommand(),
// not
SqlConnection.IDbConnection.CreateCommand(),
// which is suggested by MSDN.
}
///------------
The above client code has violated the programming rule: "PROGRAMMING
TO INTERFACE".
According to the MSDN, we can not "PROGRAM TO IDbCommand".
The action of "SqlConnection.CreateCommand()" is difference with the
action of"IDbConnection.CreeateCommand()".
Now if i want to shift to the Oracle database. All of the client code
must be modified, because the above is "PROGRAM TO SqlCommand". :-(
What a foolish ADO.NET FrameWork.
I am a java programmer. If i design the SQLConnection, i will give a
such a implemention:
///--------
SQLConnection:IDbConnection {
....
IDBCommand CreateCommand() {
........
}
SqlCommand CreateSqlCommand() {
........
}
....
}
///---------
If the client programmer want to "PROGRAM TO SqlCommand", he will call
the method of SqlConnection.CreateSqlCommand(). If the client
programmer want to "PROGRAMM TO IDbConnection", he will call the
SqlConnection.CreateCommand(). Now The action of
"SqlConnection.CreateCommand()" is same as the action
of"IDbConnection.CreeateCommand()".
Because the client code is "PROGRAM TO IDbCommand", so if the client
program shifts to Oracle database, the client code will not have to
modify all the code.
Frans Bouma [C# MVP]
of course it will give an error, you can't differ an overload by just
the return type.
do:
public class SqlConnection: IDbConnection
{
public SqlCommand CreateCommand()
{
//...
}
IDbCommand IDbConnection.CreateCommand()
{
return this.CreateCommand();
}
}
> if we write the code as follows:
> ///---------
> SQLConnection:IDbConnection {
> ....
> SQLCommand CreateCommand() {
> ........
> }
>
> IDBCommand CreateCommand() {
> .......
> }
> ....
> }
> ///---------
> The compiler will give us an error. THE COMPILER DOES NOT TAKE THE
> RETURN TYPE INTO THE COMPILE PROGRESS.
which makes sense. Don't repeat yourself, look at the language spec.
It's not eiffel, it's C#.
> so the SQLConnection have to implement the
> IDbConncection.CreateCommand explicyly.
> ///--------
> SQLConnection:IDbConnection {
> ....
> SQLCommand CreateCommand() {
> ........
> }
>
> IDBCommand IDbConnection.CreateCommand() {
> return this.CreateCommand();
> }
> ....
> }
> ///---------
> The above is the SQLConnection.
correct.
When I lookup IDbConnection.CreateCommand, I don't see any warning
that I shouldn't use it in my code. If I go to SqlConnection, I can use
it in generic code which simply uses interfaces. The fun thing is: if I
do:
IDbConnection con = DalCore.CreateConnection();
IDbCommand cmd = con.CreateCommand();
it works, because SqlConnection.CreateCommand returns an IDbCommand.
> I am a java programmer. If i design the SQLConnection, i will give a
> such a implemention:
> ///--------
> SQLConnection:IDbConnection {
> ....
> IDBCommand CreateCommand() {
> ........
> }
>
> SqlCommand CreateSqlCommand() {
> ........
> }
> ....
> }
> ///---------
> If the client programmer want to "PROGRAM TO SqlCommand", he will
> call the method of SqlConnection.CreateSqlCommand(). If the client
> programmer want to "PROGRAMM TO IDbConnection", he will call the
> SqlConnection.CreateCommand(). Now The action of
> "SqlConnection.CreateCommand()" is same as the action
> of"IDbConnection.CreeateCommand()".
> Because the client code is "PROGRAM TO IDbCommand", so if the client
> program shifts to Oracle database, the client code will not have to
> modify all the code.
I use IDbConnection.BeginTransaction in my code and never had a
problem, because it works as expected: every connection object of all
the providers I use (6 of them) implement that interface.
jinfen...@msn.com
this your code:
IDbConnection con = DalCore.CreateConnection();
IDbCommand cmd = con.CreateCommand();
you have realized the problem of the ADO.NET Framework, and encapuslate
the SqlConnection with the DalCore. yeah?
"DalCore.CreateConnection()" returns the interface of IDbconnection,
so all of the following code are PROGRAMNING TO INTERFACE.
For the beginner, what they can do is just copied the code from the
MSDN.
but, MSDN suggested that "you should never call the
SqlConnecton.IDbConnection.CreateCommand(). "
The one who obey the MSDN advices will bring out a stupid code, which
can not shift the SQLConnection to OracleConnection , and so on.
Look at the code:
///-----------
public interface MyInterface
{
object getobject();
}
public class MyImplemention:MyInterface
{
object MyInterface.getobject()
{
Console.WriteLine("return object()");
return new object();
}
public object getobject()
{
Console.WriteLine("return string()");
return "";
}
}
internal class Class1
{
private static void Main(string[] args)
{
MyInterface i = new MyImplemention();
i.getobject();
Console.ReadLine();
}
}
///-----------
The ouput is : "retrun object()". "i.getobject()" is calling the
"MyImplemention.MyInterface.getobject()".
I agree with your opinion, but opposite to the MSDN advice.
"con.CreateCommand()" is calling
"SqlConnection.IDbConnection.CreateCommand()", which is not suggested
by MSDN. yeah?
What I emphasised is that : the action of
IDbConnection.CreateCommand() is different from the
SqlDbConnection.CreateCommand(). This is the evil of origination.
Anyway, thanks a lot. thank for you kindness.