Where is my SQL Server Management Studio?

If you should stumble across this blog, I bet you have encountered the same problem I did. After you installed the Microsoft SQL Server 2005 you cannot find the SQL Server Management Studio in your Start menu, and if you try to search for the SqlWb.exe it's nowhere to be found. In my situation I had installed Visual Studio 2003, Visual Studio 2005 and Visual Studio 2008 prior to the SQL installation.

The problem is that the installation of the SQL server will interpret the installation of the SQL Express Edition as a newer version or an already installed client tool.

So the solution for you may be to uninstall the SQL Express. I had a Windows 2003 64x Server so I had to uninstall (via the Add or Remove programs) the "Microsoft SQL Server 2005" (which was the Express instance, installed by Visual Studio 2005/2008). I then reran the SQL Server 2005 installation and ensured that the Client tools were selected (click the advanced button in the installation wizard).

After this I had the Management Tools back on the machine, but now I couldn't open the Express database in my VS 2005 project so I had to install the SQL Express again by rerunning(updating) the Visual Studio 2008.

Happy sqling and programming

Illegal Cross Thread Operation?

I see many forumposts solving this problem by simply adding the CheckForIllegalCrossThreadOperations=false;

While this is a totally legit workaround, it is highly thread-unsafe, and should only be used for debugging purposes. To be able to update for instance form-components from another thread, you will need to use delegates and invoke. Sounds scary? Not really.

A delegate is simply a "blueprint" that describes how a particular function or method should look. In C++ world, delegates are similar to Function pointers, but since we don't work with pointers in C# this is the closest we get. Still, function pointer is not a correct definition, as the delegate won't point to a function unless you make it do so. Here's an example:

The function


private void UpdateStatusText(string statusText)
{
statusLabel.Text = statusText;
}


Would have the following delegate:


public delegate void UpdateStatusTextHandler(string statusText);


Both the delegate name and the parameter-name(s) are totally random, it is the return-type and parameter-types that are important.

Let's say we have an eventhandler thread_OnStatusChanged(string newStatus) that needs to update the statusLabel.Text property. If the thread is different from the one the statusLabel exists in, you will get the Illegal Cross Thread operation error if you simply try to update it.

What we first want to do is an if-check to see if it comes from a different thread.
Inside the thread_OnStatusChanged eventhandler we do the following:



if (statusLabel.InvokeRequired)
{
statusLabel.Invoke(new UpdateStatusTextHandler(UpdateStatusText), newStatus);
}



The Invoke function takes the arguments Delegate Method, as well as the optional args[] to enable you to pass the required arguments to your method.

So by doing the new UpdateStatusTextHandler(UpdateStatusText) you are simply creating a pointer to the method UpdateStatusText(string statusText)



Hopefully this will make delegates and invoking a little more understandable.

Good luck with your threads!

Managing Unmanaged Resources

Unmanaged Resources are objects that are not garbage collected, which means that they are not reclaimed by the system when the garbage collector cleans up after you.

But are Unmanaged Resources resources outside .NET framework like DLL used through interop? No, unmanaged resources can also be database connection. It is a common mistake by programmers not to close the connection when finished working with it, in misconception that the garbage collection will close it.

So how do I identify if the object is an unmanaged resource? If the object implement the IDisposable interface it have an unmanaged resource and you need to call the IDisposable.Dispose() method to clean the objects unmanaged resource.
If you use the object in a single call you can wrap it in a using statement (http://softscenario.blogspot.com/2007/10/using-using.html), and it will call the Dispose() method for you. If you keep the object for a longer time you must support the IDisposable interface in your class, and in your implementation of the Idisposable.Dispose() call the member's IDisposable method.


Remember to look for the IDisposable interface in the classes you use in your development. You will be surprised how many classes that do.

Where are my Properties.Settings saved

Have you ever wondered where your user settings are saved from an .NET application? You would probably think that it's saved in the [application].exe.config(located in your application folder) file, but this is only partially true. The default values you create in Visual Studio are saved in this file. But if you change these settings at runtime:

Properties.Settings.Default.myValue = "MyNewValue";
Properties.Settings.Default.Save();

they are saved to a different location. Namely the User.config file:

C:\Documents and Settings\[USER]\Local Settings\Application Data\[company]\[applicationname]\[version]

Note that if you should change the company name or AssemblyVersion attribute in your AssemblyInfo.cs your Settings will be saved in a new location.

Since you do not override the default settings in the exe.config file, you can call the reset() method to restore the settings to its original state:

Properties.Settings.Default.Reset();