As you may all know I have Windows Vista Ultimate x64 and last post I talked about upgrading to SQL Server 2005 SP2. However while starting my first Database Project I encountered the following error.

—————————
Microsoft Visual Studio
—————————
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
—————————
OK
—————————

It has basically taken me around 24 hours to finally find a solution. The solution was so simple, but yet totally undocumented on if you encounter this error do this. So I am hoping to at least correct that with this post for all the future Googler’s out there.

1. In VS 2005 go to Tools > Options > Database Tools > Design-time Validation Database and clear out text box SQL Server Instance Name. Click OK.
2. Also for good measures I did this under Database Connections too.

Yeah that is it for some reason localhost isn’t considered a valid SQL Server Instance name. But my problem is solved and I hope this helps somebody else.

Tags: .Net, Microsoft, SQL Server

Posted in C#, Programming, SQL | | | View blog reactions | 1 Comment »

The System.IDisposable interface is a very useful interface to understand if you are concerned about performance in your application. Microsoft says the following about the IDisposable interface:

The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used, however, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.

Most System.Data, System.IO and System.Windows.Controls objects use the IDisposable interface, as well as many others, to free up unmanaged resources that may have been created when the object was initialized. Unmanaged resources are any calls that are made outside of the .NET environment, this can be GDI+ calls, SQL Driver calls, Disk IO calls, or basically anything that cannot be accounted for by the Garbage Collector.

Often times you will see database connection code that looks like this:

SqlConnection conn = new SqlConnection("{connection string}");
SqlCommand command = new SqlCommand(conn);

command.CommandText = "select * from SomeTable";

// ... some more code to use the command

conn.Close();

However there are a problem with this code, the unmanaged resources for the SQL connection have not yet been destroyed in memory. The correct way this code should have been written is the following:

using (SqlConnection conn = new SqlConnection("{connection string}")) {
	using (SqlCommand command = conn.CreateCommands()) {

	command.CommandText = "select * from SomeTable";

	// ... some more code to use the command

	conn.Close();
	}
}

And if you were to look at this code under a microscope the following code is actually what is happening:

SqlConnection conn;
SqlCommand command

try {
	conn = new SqlConnection("{connection string}");
	command = new SqlCommand(conn);

	command.CommandText = "select * from SomeTable";

	// ... some more code to use the command
} finally {
	conn.Close();
	command.Dispose();
	conn.Dispose();
}

So essentially even if an exception is thrown from your code, the unmanaged code is still cleaned up and you don’t have memory leaks from unmanaged code sitting around in memory waiting to be reclaimed. It is reclaimed instantly after you are done working with it.

If you would like to learn more about the code used above please see these links

• using Statement
• try-finally Block

Tags: .Net, Framework 1.0

Posted in C#, Programming | | | View blog reactions | 4 Comments »