SQLTeam.com | Weblogs | Forums

Program has no access even though the port is open


Hey all, a former coworker wrote a small program to allow a workstation to send out emails from a SQL query. I upgraded the SQL 2005 to 2012 and the program no longer works. The coworker is no longer here and I'm trying to find the problem but now I'm baffled -- Wireshark says the program is accessing SQL through port 445, NMAP says port 445 is open (and in the firewall settings on the server port 445 is open), but the program can't access SQL unless I disable the firewall. I checked the Connections settings and the Allow remote connections to this server check box is checked. I'm still not a SQL guy (but I now have a couple of books) so I'm not sure what else I should be looking for. Any ideas? Suggestions? Recommendations?


Joe B


the default port for sql server is 1433. you'll have to check sql configuration manager, tcp settings to see if this has been changed to 445. otoh sending email from sql is easy. sp_send_dbmail (google id) will do the trick


Hi gbritton, I guess I should have added that 1433 was already open. My other users who are working with this SQL server aren't having any problems.

As to email, we're not sending emails from SQL; they are being sent from three workstations. I had to go in and set up relaying on my Exchange server and then add those workstations to the relay access group. As I understand it the program my former coworker wrote interrogates AD, maps that with some groups in SQL and then it emails members of those groups. It all works as long as the firewall is turned off.


Joe B


Anyone have any wild, shoot-from-the-hip suggestions? I'll consider just about anything at this time.


Joe B


I don't recall the details, but port 445 was associated with named pipes or in-memory connections in older versions of SQL Server. Are you able to open up the client program and look at the connection string used to connect to the SQL Server?


This is from the .exe.config file:

<add name="Name_Of_Report.Properties.Settings.1234_SQLConnectionString"
    connectionString="Data Source=SRV-Server2;Initial Catalog=1234_SQL;Integrated Security=True"
    providerName="System.Data.SqlClient" />
<add name="Name_Of_Report.Properties.Settings.4321_SQLConnectionString"
    connectionString="Data Source=SRV-Server2;Initial Catalog=4321_SQL;Integrated Security=True"
    providerName="System.Data.SqlClient" />

That's about the extent of what I can see regarding the connection strings.

At this time I have the bookkeeper call me when she starts this process so I can turn off the server's firewall. Then when she lets me know she's done I turn it back on again. It's a bit of a pain but at least it works this way.


Joe B


There is no port in the connection strings, so the default port (1433) would be used.


GBRITTON! Ok, I took another look at the configuration of port 1433. This time I noticed that the Remote IP Address scope was set at Local Subnet so I checked the bookkeepers' IP addresses and they're in a different subnet. I changed Local Subnet to Intranet and it works now. Thanks for the comment on port 1433; that's what prompted me to take another look at it and figure it out.


Joe B



Glad you worked it out!