Testing for network connectivity via opening a database connection

I have a little .net 2.0 systray app (C#) that checks for network connectivity periodically. It does this by attempting to open a connection to a SQL-Server instance on开发者_Go百科 another computer (and selection a row from a table). The application saves documents created by another process to a database when it finds a connection. It is going to be used in environments with potentially dicey wireless networks.

In testing our QA team is using ipconfig /Release on the DB server (hosting a Sql-Server 2005 DB). What we found was that the application continued to claim it was network connected, because it kept right on successfully opening connections to SQL Server. I found the systray app's behavior erratic in my own testing using ipconfig /release.

At the suggestion of our not-currently-present network guy I changed my own internal testing (app hosted on a VM, connecting to DB on my workstation) to instead turn off the VM network connection. This produces the expected behavior (the systray app can't find a network connection). The QA guys are a little leery about my suggested that they do the same, and I need to put them at ease.

1. It was suggested to me that SQL Server was using named-pipes to accept incoming connections. If Named Pipes and TCP/IP are enabled, does this invalidate the ipconfig /release test?

2. I don't really know much about networking. Named-pipes, according to what I have read, sounds like it is designed for use between applications on the same server. But it can be used for intranet communications?

3. Is there something else going on here that I an unware of? Something about how ipconfig /release works

---

For your application, I would only use TCP/IP communication protocol. Although SQL Server supports other communication protocols such as named pipes, I would disable them on your server so it only accepts TCP/IP connections. This is least amount of overhead and should perform the best regardless of connection speed.

Named pipes is a different protocol then TCP/IP, so releasing the IP address may not effect named pipe communication in any way (Sounds like it is).

On the SQL Server machine, put TCP/IP as the number 1 protocol and disable named pipes. The have QA re-run the test. I have included a configuration screen shot for reference.