Member Avatar for slacke

Hello everybody.

How do you do?

I have a really odd problem. I am using an application which is running on MS OS-es. (MS Windows XP SP3, MS Server 2003) This application connects to a remote SQL server (MS Server 2003). The version of MS SQL was 2000 (previous free version). Now I need to run the latest MS SQL express 2005 server (Version: 2005.090.4035.00).

The problem is that no matter what I do it just does not allow remote connection. I found several links how to enable the remote connections but it doesnt work.
http://support.microsoft.com/kb/914277
This is the output of netstat -a -n

TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1433           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:28729          0.0.0.0:0              LISTENING
  TCP    127.0.0.1:1041         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12025        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12080        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12110        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12119        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12143        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12465        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12563        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12993        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:12995        0.0.0.0:0              LISTENING
  TCP    192.168.10.16:139      0.0.0.0:0              LISTENING
  TCP    192.168.10.16:1052     192.168.10.16:1433     ESTABLISHED
  TCP    192.168.10.16:1433     192.168.10.16:1052     ESTABLISHED
  UDP    0.0.0.0:445            *:*
  UDP    0.0.0.0:500            *:*
  UDP    0.0.0.0:1030           *:*
  UDP    0.0.0.0:1031           *:*
  UDP    0.0.0.0:1434           *:*
  UDP    0.0.0.0:4500           *:*
  UDP    127.0.0.1:123          *:*
  UDP    127.0.0.1:1029         *:*
  UDP    127.0.0.1:1055         *:*
  UDP    127.0.0.1:1900         *:*
  UDP    192.168.10.16:123      *:*
  UDP    192.168.10.16:137      *:*
  UDP    192.168.10.16:138      *:*
  UDP    192.168.10.16:1900     *:*

It looks like the service is running on the 1433 port (as it is required) but it doesn't accept the tcp connection (no answer for SYN).
No firewall is blocking the connection. I don't know if this is possible but it looks like the port is already connected with the same IP (as the server has).

Do anybody have some experience with this MS SQL server. What do I miss?

  • 2 Contributors
  • 3 Replies
  • 2K Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by lolafuertes

Dani AI

Generated

Good catch by on the firewall. When netstat shows 0.0.0.0:1433 listening and only local ESTABLISHED sessions, the next things I check are below. These complement ’s notes about enabling TCP/IP and Named Pipes.

  • Confirm the SQL 2005 setting that actually permits remote connections. In SQL Server Surface Area Configuration, set Database Engine -> Remote Connections to “Local and remote connections” (TCP/IP, or both). Then restart the service. SQL Server 2005 Express disables remote access by default, so this toggle matters. (documentation.help)
  • If your app can only use an IP and not an instance name (as you mentioned), give the instance a fixed TCP port and connect with tcp:IP,Port. You can test from a client with:
    sqlcmd -S tcp:192.168.10.16,1433 -E -Q "SELECT @@VERSION" (learn.microsoft.com)
  • If you ever use a named instance and do not specify a port, the SQL Browser service must be running and UDP 1434 must be allowed inbound; otherwise specify the port explicitly and you can skip Browser. (learn.microsoft.com)
  • Double‑check the firewall’s real state on Server 2003/XP and open the port if needed. For example:
    netsh firewall show state
    netsh firewall add portopening TCP 1433 "SQL Server" ENABLE
    You can also verify/open rules using the older netsh “firewall” context on 2003. (learn.microsoft.com)
  • From a remote client, validate the path isn’t filtered with PortQry:
    portqry -n 192.168.10.16 -p tcp -e 1433
    LISTENING means the port is reachable; FILTERED usually points to a firewall between client and server. (learn.microsoft.com)

Tip: SQL’s error log prints the exact port it is listening on; handy for confirming static vs dynamic ports after changes. (learn.microsoft.com)

Recommended Answers

All 3 Replies

Member Avatar for lolafuertes

Did you used the SQL Server Configutration Manager on the server and verifyed the Protocols? Usually you need to enable TCP/IP and Named Pipes (Shared Memory is by default).

Also, in the client, you need to enable them and set the order to Shared Memory, TCP/IP and Named Pipes.

Please let us know
Hope this helps

Member Avatar for slacke

Unfortunately the problem was with the error in the avast firewall. I use AVAST internet security which contains an inbuilt firewall. This firewall normally turns off the windows firewall at installation time and use its own. When I was turning off the firewall I did it in avast. Unfortunately the avast didn't worked well and it didn't turn off the windows firewall. I have no idea why ...
As the port-scan from outside showed that the port is closed I already knew that something is wrong with the firewall.

Now I can connect with the SQL server. Thanks for your reply.
What you noted was also required - the application which uses the SQL Server has a simple utility called ConnectionManager which can work only with IP address.
The name of instance cannot be defined.

Member Avatar for lolafuertes

Glad to hear you solved it.

Please, be so kind to mark the thread as solved.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.