VB6应用程序可以连接到SQL Server，但.NET应用程序不能

Question

Our system uses a combination of VB6 legacy applications and newer .NET applications. The applications are deployed to our clients, and they run the applications from a Terminal Server box, with the SQL Server database running on a different box.

The VB6 applications work fine, while all of the .NET applications fail on startup (trying to connect to the database to read configuration information) every time with the error:

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)

Here's the really weird thing: I created a test .NET application in C# that replicates the exact connection string used by the .NET applications -- I deployed an instrumented version of one of the applications that displays the actual connection string used -- and the test app works .

VB6 connection string (works): Provider=SQLOLEDB;Data Source=servername;Initial Catalog=databasename;User ID=username;Password=password;

.NET connection string (both works and doesn't work): Data Source=servername;Initial Catalog=databasename;User ID=username;Password=password;Application Name="ourappname"

None of our other clients have experienced this issue with the same binaries, which tells me it's a problem with how the .NET applications are interacting with this particular client's system.

What steps should I take to troubleshoot/fix this issue? I'm really at a loss at this point. I'm hoping someone else has seen this issue before; I couldn't find anything relevant on Google.

---

• Both boxes are Windows Server 2008 R2 SP1 running on VMWare, and are in the same domain
• Both boxes run ESET NOD32; disabling didn't change anything
• SQL Server is a default instance of 2008 R2 RTM (there are also 2008 and 2008 R2 named instances on the same box)
• The applications (and my test app) are .NET 4.0
• The application uses a SQL login to authenticate (yes, I checked that the password being used by the failing apps is correct)
• Some of the .NET applications use different code to do application startup, yet they all exhibit the same error
• Some of the .NET applications are C#, some are VB, some are mixed (VB apps, C# core assemblies)
• I've tried repairing the .NET 4.0 install
• I've tried rebooting both boxes
• I've tried deploying the source binaries such that our deployment subsystem was circumvented (in case it was causing corruption of some kind)
• The instrumented application which I compiled locally experiences the same behaviour as the original, which was built via Team System

Answer 1

I have found that there are usually a few primary causes of this behavior:

1. SQL Server is not configured to listen for the specific connection type. To determine this, open SQL Server Configuration Manager on the SQL Machine, click the SQL Server Network COnfiguraiton and then Protocols for MSSQLServer. Verify that TCP/IP is enabled.

2. SQL Server not allowing remote connections (if other apps are connecting, then this is obviously not a problem).

3. The client machine is not configured to talk to SQL Server using SQL Server's supported protocols OR the the client machine has incorrect configuration information entered. To verify this, run cliconfg from the Run... prompt and ensure the appropriate protocols are enabled and that there aren't any conflicting aliases in the Alias tab. I usually add one specifically for the machine name configured in the connection string with the appropriate IP address in case there is a DNS issue (at least for testing).

4. Since VB6 clients work and .Net clients don't there could be an issue with 64-bit versus 32-bit access. If your app is compiled for 64-bit or Any CPU, you may try a 32-bit build to see if that resolves the access. If so, then this is most likely a 64-bit SQL Client configuration issue.