0

I have built a winforms application which is installed on client machines with an SQL Server Database hosted on a server which clients access via remote connection.

The application works as planned on the server and one client but when I try o access the same data from a second client I get a "pre-login handshake" error.

On researching I found a number of solutions, some stating that I needed to enable IPV4 and IPV6 which I did, others stating that I needed to enable remote connection which was not the problem as the other client already accesses it.

Can anyone give me any pointers as to what the problem might be?

The client that works runs: 64 bit processor, Windows 8 OS. The client that doesn't runs: 32 bit processor, Windows Vista.

Clents also access the app via ClickOnce over a local network. Application target OS is currently set to x64. I will switch to any CPU and x86 and report if there are any changes when I get to the office.

Ozone Developer
  • 83
  • 9
  • 2
    A firewall somewhere between your server and the misbehaving client might be blocking access to the SQL Server port. – Eric J. Oct 16 '14 at 22:39

1 Answers1

0

Check the network

The fact that your x64 box can see the server but your 32-bit box can't is odd. Are both boxes attached to the same switch or do they reach the server via different network paths? As Eric stated, there may be firewalls blocking the SQL Server port between the 32-bit machine and the SQL box.

Also, from the failing machine, check what network address it thinks the SQL Box lives at:

C:\> nslookup TestSQLServer
Server:  dns1.internal.foo.com
Address:  10.1.10.2

Non-authoritative answer:
Name:    TestSQLServer
Address:  10.1.10.141

If your DNS returns an IPv6 address for your SQL box, be sure the failing client has IPv6 installed and enabled.

Check your SQL Server

As discussed in this thread, try setting your SQL Server to listen to a specific network interface and try connecting to that interface's IP address. NB: Do NOT hard-code your client code to talk to this IP address if it's dynamically allocated via DHCP.

Also check which port your server is listening on - if its been changed from the default, you'll have to specify the port number in the client's connection string/code.

Check your connection to SQL Server

I recommend thoroughly testing the network between your failing client and the server.

  1. Test that your failing client can see the SQL Server on the network

    1. Use the "ODBC Data Sources" control panel applet to create an ODBC connection to the SQL Server from the failing client. Use the "Test Data Source" button

    2. Test that you can connect to the SQL Server from the failing client using SQLCMD. Be sure to connect using the same credentials that your client uses to login to SQL Server E.g:

      sqlcmd -S TestSQLServer\TestInstance1 -D TestDB -U TestUser -P TestPassword -Q select * from TestData

Community
  • 1
  • 1
Rich Turner
  • 10,800
  • 1
  • 51
  • 68