hi, I have a question about the difference between
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.

JinFeng,

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

hello, Cor . thanks for you answer. but it's not what i want.

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.Disp­ose()"
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.Disp­­ose() and SqlConnection.Dispose()
shared the same source code? and why MS tell us that there exists a
"SqlConnection.IDisposable.Disp­­ose()" 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.

JinFeng,

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

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemidisposableclasstopic.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemidisposableclassdisposetopic.asp

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

jinfeng_W***@msn.com wrote:

Show quoteHide quote    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

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 want to know the difference between the two method of
SqlConnection.IDisposable.Disp­­ose() and SqlConnection.Dispose().

Thanks to you!!! thanks!

jinfeng_W***@msn.com wrote:

    I thought that it meant that, but checking SqlConnection in reflector
I couldn't find IDisposable explicit implementations :D Hence my
question :)

    I have no idea.

        FB

copied from Reflector:

System.Data.SqlClient.SqlConnection.System.Data.IDbConnection.BeginTransaction()
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. ~

jinfeng_W***@msn.com wrote:

Show quoteHide quote    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.

        FB

It's foolish.
i have know the reason. :-(

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.

Show quoteHide quote

William (Bill) Vaughn wrote:

    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...

thanks all of you.


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.Disp­­ose() " 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.Disp­­ose() and SqlConnection.Dispose(),
then MS has no need to implement the
SqlConnection.IDisposable.Disp­­ose() 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.Disp­­ose() 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, :-(

jinfeng_W***@msn.com wrote:
    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.

    Have you looked into the code with reflector ? I think you should do
that. :)

Show quoteHide quote    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.

    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

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.

firstly, let's take a look at the following code.

///--------------
    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.

jinfeng_W***@msn.com wrote:

Show quoteHide quote    of course it will give an error, you can't differ an overload by just
the return type.

Show quoteHide quote    do:

public class SqlConnection: IDbConnection
{
    public SqlCommand CreateCommand()
    {
        //...
    }

    IDbCommand IDbConnection.CreateCommand()
    {
        return this.CreateCommand();
    }
}

Show quoteHide quote    which makes sense. Don't repeat yourself, look at the language spec.
It's not eiffel, it's C#.

Show quoteHide quote    correct.

Show quoteHide quote    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.

Show quoteHide quote    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.

        FB

to FB:

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.

How to insert rows into tables with Autonumber PKey by using DataSet and DataAdapter?
Joins with Datatables
Need advice for tracking down a general network error exception
Why not a view...?
DataSet scan efficiency