As PIEBALDconsult said: if you create it, you should dispose it when you are finished with it.
The problem is that some objects use scarce resources, and unless they are disposed those resources do not become available for other classes within your app, or other applications until the Garbage Collector identifies them as unused, or the app ends. Since this may not happen for minutes, days, or even months, it is a very good idea to get into the habit of Disposing everything which implements IDispose. This is particularly true of SQL components, Graphics releted items, and files.
You may not notice a problem, but it is potentially there to bite you in production, and extremely difficult to track down and fix - since all you get is normally "out of memory" errors, with no indication of what caused it.
The easiest and cleanest way if to wrap the object in a using block as this also takes the object out of scope when it is Disposed, so that it cannot be accidentally referenced later.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
You should dispose of instances which you are 'in charge of' (i.e. you created and have not handed out persistent references of to other classes), when you are done with them.
Because of how database interaction is limited (concurrent connections usually being the limiting factor), you usually want to create, use and dispose of connections, commands and transactions quickly. For this you should use a using statement.
you usually want to create, use and dispose of connections, ... quickly
Buuut... Connections use connection pooling; they don't actually use a connection until you open it, then it's returned to the pool when you close it. So you can hold onto a Connection for a long time and only open it when you need it.
i see what ur saying. there's a clear diff b/t the (conn) object and what you do with it (opening/closing). don't destroy it if ur going to keep using it, etc. (for conn obj).
tnx for the 'using' tips et al.
For a moment, let's assume that we are talking about a SqlConnection here. When you call Dispose on the connection, all it does is call Close and then calls Dispose on the object it derives from (which just fires off the EventDisposed event to any listeners, and removes the instance from any SiteContainer instance. So, what does all this have to do with the price of fromage?
Well, the only part that is of any real interest there is the Close, so given that this is all that the Dispose is really doing, you are fine keeping the connection available for use, and just use Close on it until you really are ready to get rid of it.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
So you can hold onto a Connection for a long time and only open it when you need it.
True but in normal practice that shouldn't happen.
First the significance in the object is the connection. If there is no connection then the object itself is light weight so creation itself isn't doing anything (again for most situations.)
Second if you keep it around you must explicitly manage the state. So to reuse it you would need to either explicitly check the state or implicitly assume the state is correct. The first case requires additional code and the second leads to complexity as the maintenance engineer would need to insure correct state. Both of those cases are more easily solved by using creation.
I have no problem with that. I've written Windows Services that hold a single Connection for months and never had any trouble using Open and Close as needed, perhaps millions of times.
I didn't say it couldn't be done. And usage of course would have nothing to do with whether it was correctly implemented in all cases except of course that if there is an incorrect usage then it is more likely to show up with high volume.
I develop a windows application using c# that use sql server databases, i want to create a setup for this application to install application and install sql server as prerequisites, but i want to set a specific configuration for this sql server such as instancename, sa password and mix mode.
Installing SQL Server is not trivial and you would need to deal with licensing issues as well. There are other issues as well such as whether SQL Server is already installed and whether the user has SQL Server but has it on another box.
The license problem by itself would concern me. But just automating the SQL Server install is going to require a lot of work.
But I would suppose that to do automation that you would need to look into custom actions in the installer.
I agree with jschell and Paul Conrad, but it is easy to but sql express as a prerequisites in c# deployment problem, but i want it to installed with my configuration not the default settings,
is it possible to do that?.
It could be necessary to install a new version of Windows Installer before that.
After installation of SQL server, the database can be restored/attached by a call to osql with many parameters.
I don't know all the details, but with this information you can start and try.
I believe that it is always a serious mistake to show a Form inside another Form ! Only in the long outmoded, so called, "MDI interface" mode did you have Child Forms within a 'master' Parent Form: that is no longer considered a useful interface model.
I second OriginalGriff's suggestion to either use a Panel, or a UserControl, to display whatever inside a Form.
The really good thing about building UserControls, is their potential for re-use in other projects, or use of multiple instances of them in one project.
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
staticexternint SetParent( int hWndChild, int hWndNewParent);
int hWnd, // handle to window
int hWndInsertAfter, // placement-order handle
int X, // horizontal position
int Y, // vertical position
int cx, // width
int cy, // height
uint uFlags // window-positioning options