Thursday, July 15, 2004

Setting up SQL Server 2005 "Yukon" and Visual Studio 2005 "Whidbey"

I'm sure this is academic for some, but I'll run through how I setup these two beta applications and got them talking.


I should probably start off with some background on setup. I have a Windows Server 2003 (referred to as "the server" below) system running MS SQL Server 2005 Express (essentially Beta 2) and MS Visual SourceSafe 6.0d. Another system on the LAN running Windows XP with Visual Studio 2005 Beta 1 (referred to as "the LAN system" below). And finally, I have another Windows XP system running Visual Studio 2005 Beta 1, but the system is located outside the firewall with VPN access (referred to as "the remote system" below). I won't go into the specifics of what VPN solution, but that may play an important part on the remote access to the SQL Server for different people in different environments.


One other noteworthy thing about environment is that these systems are set apart from the domain (Windows 2003 server setup as a standalone system).


After installing Yukon and Visual SourceSafe on the server and VS 2005 on the LAN and remote systems, we were able to open the VSS project by selecting File - Source Control - MS Visual SourceSafe and then entering the properties of the SourceSafe database. Once the connection was setup, we could then choose File - Open - Project/Solution, then select MS Visual SourceSafe, the database we already attached to, and finally select a solution. In only mention this since MS moved the Visual SourceSafe call for opening a VSS project from Visual Studio.


This is the point at which the LAN system and remote system split paths. For the LAN system, we had some difficulty adding a connection to the server. When attempts where made, we kept getting the error: No connection could be made because the target machine actively refused it. As it ends up, we forgot to install the Visual Studio Remote Debugger. One thing that also needs to happen is to happen is to enable TCP traffic for SQL Server and start the SQL Browser service. To enable TCP traffic, open the SQL Computer Manager, drill into Server Network Configuration - Protocols for . Once you click on the Protocols, you should see SM (shared memory), NP (named pipes), TCP, and VIA (Virtual Interface Architecture). Right-click TCP and select Enable. Once TCP is enabled, open up the Services window, locate SQL Browser and double-click it, then select a Startup Type of Automatic, and (finally) click start. Once that was up and going, the LAN system worked like a champ.


I had trouble with the remote system, but found out that it was a performance issue. As I was trying to connect, I also had a fairly large file I was copying to another destination. I continually received the following error: Unknown ProviderError Locating Server/Instance Specified. Once the file completed the upload, I was able to connect without any problems. If anyone is getting the error above, I suggest looking at bandwidth (although I'm sure that isn't the only way to receive that generic error).

No comments: