>>>>Hi all,
>>>>
>>>>I've cmoe across a weird situation that I can't get around. A customer has an SQL instance on a server and we want to start using it. Standard enough so far and I wrote a small prg that connect to the SQL server and inserts a row. On the Server it works no problem, with both windows authentication and SQL authentication in the connection string.
>>>>The problem is that on the network if I try to run this simple program it fails. The program does not make a connection to the server. I have tried opening ports on the server and the client pc but no difference. I have also tried turning off the AV but no difference. I've gotten it to the point where I can telnet to the server on port 1433 but still the connection fails. Initially the telnet was failing as well but I changed the dynamic port in the SQL configuration.
>>>>On a different client PC i installed sql server 2008 and then was able to use my program to insert into the SQL database on the server, but I can't go installing SQL on every client PC.
>>>>Server is Win server 2008R2 and SQL server 2008. There were 3 instances of SQL running, 2 have now been uninstalled as they are no longer used.
>>>>Any idea on what to try next or any tool to use? I've googled and confirmed all the regular settings are correct.
>>>
>>>You may need to take a close look at the firewall on the server. In some cases you may need to enable the service (essentially an EXE) to accept incoming connections, in addition to or instead of just opening specific port(s). Depending on the firewall, it may already know about the running service and allow you to enable/disable it directly. If not, you may have to create a manual exception by specifying the EXE you want to allow. You can get this by going into the Properties of the MS SQL service in the Services control panel.
>>>
>>>All of this assumes there's only a software firewall between the server and the client machine you're working on. If there are any other routers/firewalls in the path, you may have to configure those as well.
>>>
>>>Come to think of it, if there's a strict/aggressive firewall on the client, you may need to configure it as well.
>>Thanks Al,
>>I've been working on the assumption that it is a firewall setting. The EXE for SQL Server and the configuration manager are both allowed in the firewall. The firewall is the windows firewall, I have also turned off Trend as that is the AV solution onsite.
>>I can telnet to the server ip with port 1433, but connection fails in the program, so there is some connectivity at a basi level.
>
>OK, this is kind of a dumb thing but I have to ask.
>
>Being able to telnet into a host requires that a telnet server be running on it. The normal telnet port is 23. It sounds to me like you've reconfigured the telnet server on the host to listen on port 1433.
>
>You can't have two separate programs listening on the same port. So, if you have a telnet server listening on 1433 while you're trying to connect to SQL Server (also nominally listening on that port) then the SQL connection will almost certainly fail.
>
>You will need to make certain the telnet server is not running while you're doing your SQL connectivity tests.
I don't modify the telnet port I only use telnet to see if the server will accept a connection on a port. When I get a connection I get blank screen which I've always taken to mean that the port is open but as it's not port 23 I can't do anything with it. I was using it more to prove that the connection can be made.
~M