views:

52

answers:

2

I recently posted (and promptly deleted, when I decided the question was irrelevant to the actual problem) a question about SqlConnection losing its Database information when the scope of "ChangeDatabase" ends. Example:

    //Other code...
    dbConn = new SqlConnection(dbConnBuilder.ConnectionString);
    dbConn.Open();
    dbConn.ChangeDatabase(currentDatabase);
    dbConn.Close();
}

My questions:

  1. Is it considered bad practice to hold onto a SqlConnection object and open and close it whenever you need it when you'll only ever have ONE connection of a given type?
  2. Why does dbConn.Database not remember currentDatabase after ChangeDatabase (a method not a variable) 'Goes out of scope'? (Heck, I didn't know methods like ChangeDatabase could know about scope).

My connection string was:

Data Source=server.name.com;Persist Security Info=True;User ID=username;Password=password

Thanks guys, let me know if I can give you more information, still learning to use S.O.

A: 

So just make sure to call changedatabase every time you need to execute a statement :-)

Joel Martinez
Thanks :-). That would work except I was hoping to abstract that away so I could just say: get the database and use it, not get, set up, then use it.
Cpfohl
+5  A: 

Calling Close() completely destroys the object, so you should not be reading any of its properties after.

In fact, there should even be an "after" because you shouldn't be calling Close(). Instead, instantiate the connection in a using block, so that it'll call Dispose(), which does the same thing as Close(), but is guaranteed to do so no matter how you leave the block.

Steven Sudit
So re-construction is truly the only way to go with this? (Keeping a SqlConnection around is a bad way to go?)
Cpfohl
Correct. You gain nothing from keeping it around because there's an underlying connection pool, anyhow.
Steven Sudit
The rule of thumb -- with a few sensible exceptions -- is to use `using` for anything that implements `IDisposable`.
Steven Sudit
Thanks so much!
Cpfohl
@Cpfohl: I'm confused by your question. What is the point of keeping around a `SqlConnection` object if the underlying connection has already been `Close()` d? If you want to implement your own connection pooling (which is a bad idea for other reasons), you would want to keep *open* connections around, right? Or are you trying to do something different?
Daniel Pryden
Also, it might be helpful if you include the database in the connection string, just so you can avoid changing database each time.
Steven Sudit
@Daniel, it was a lack of understanding of Close() (Imho, "Close()" is a bad name for something that destroys something, when you open or close a door it remains a connection between two rooms despite being closed. When you close an account it doesn't cease being an account, and it can typically be re-opened, etc. etc.)
Cpfohl
@Cpfohl: You're not wrong. It would have been just fine if they'd left us with just `Dispose`.
Steven Sudit
Fwiw: It would totally suck if every time you closed a door it destroyed the connection between rooms entirely.
Cpfohl