Ok, i meant was if your servers are located at remote locations(Across WAN) or Over slow networks, like our are located at Colorado and we are at Pittsburgh, Definitely we were having the issue of SLOW QUERY Responses.

What do you look for in this kind of a incident, when everything is working good as per the SYSADMINS and NETWORK ADMINS, the DBA’s are left to wander in the dark, with out any proper responses.

I started playing with protocols Named Pipes and TCPIP but hey what i found was even if you select the TCPIP in the SSMS connection box, it resolved to Named Pipes during the connection.

I tried again and with the same results and same slowness of the Query.

Ok how slow were the results: Well PRE-MOVE to Colorado, we were at a baseline of 28000 rows in 10 sec with a select * from <table name>

After the move we were only able to retrieve 400 rows in 10secs.. Well isn’t that a huge difference, and as a DBA, my Judgment was at risk and so was my performance on the EDGE.

Now I checked the CLICONFG at START-> RUN. Changed the connection to TCPIP and LO! Gods Spell worked and it worked like a charm. Well these are some hard earned but interesting and helpful lessons learned on the JOB.

http://msdn.microsoft.com/en-us/library/aa178138(SQL.80).aspx