If you saw my previous thread, this is a continuation.
By trying various things, I was able to get to the point where this code:
did allow me to see the databases I want to see. For any who didn't see the previous thread, I have a Win7 system, an XP system, and a Win8.1 system, all of which happen to have SQL Server Express installed on them. I don't really care about the XP system, in this case, but both Win7 and Win8 were able to see the DB on the XP system without any issue. The Win7 couldn't see the Win8, and the Win8 couldn't see the Win7. By enabling SQL Server Browser Agent and adding a rule to the firewall to allow for UDP over port 1434, the above code was able to see the Win8 DB from the Win7 system. I figured that I had solved the problem, and went on to other things.
Today, I got back to this, and find that, while I can see the other DB, I can't connect to it. For a variety of reasons, I set up a SQL Server login on the Win8 system and set it for Mixed Mode Authentication (though not until I tried to connect unsuccessfully without taking that step). The login works locally on the Win8. When I turn off the firewall on the Win8 system, then the Win7 connects just fine. However, with the firewall on, the Win7 system eventually errors out with a message about the server not being found. That certainly strongly suggests that this is a firewall issue, and that kind of makes sense. The firewall may not have been all that picky on XP, which might be why I have never had any issues connecting to that system. In fact, I may not have a firewall on that system, since it can't connect to the internet. Furthermore, the firewall in question is the Win8 system, as it makes no difference whether or not the firewall on the Win7 system is active.
So, upon looking at the Win8 firewall settings, I see that there is a rule for allowing TCP connections on 1433, which is called SQL Server Access. Just to be doubly sure, I followed some steps from the interwebs and created a new rule that explicitly opens TCP on port 1433 (in case I overlooked a setting for the existing rule). That had no impact. My suspicion is that the port is wrong. The default instance of SQL Server Express, which this is, as far as I can tell, should be using port 1433. It is set to use dynamic ports, but that shouldn't matter, as it looks like the default instance won't really use some other port, but will use 1433.
Ok, after writing that, I decided to test my assumptions, and am now changing tack. When I set SQL Server to use a static port 1433, rather than assuming that the default instance would use that port anyways (as the documentation states), all is well. So, the default instance was NOT using the default port 1433. That bothers me a bit. My goal is that the app will have an installation that will, in some cases, install SQL Server Express. I'd like to automate this process as much as possible, but now I come to doubt that the default installation will use a port that will make the DB accessible over a LAN through the default settings of the firewalls. It looks like the installation might use a nearly random port, which the firewall won't allow, so all the other installations on the LAN will fail.
Is this a valid concern, or is my Win8 installation a bit unusual for not using port 1433?
By trying various things, I was able to get to the point where this code:
Code:
Dim dSourceInstanct = SqlDataSourceEnumerator.Instance
Dim dt As DataTable = dSourceInstanct.GetDataSourcesToday, I got back to this, and find that, while I can see the other DB, I can't connect to it. For a variety of reasons, I set up a SQL Server login on the Win8 system and set it for Mixed Mode Authentication (though not until I tried to connect unsuccessfully without taking that step). The login works locally on the Win8. When I turn off the firewall on the Win8 system, then the Win7 connects just fine. However, with the firewall on, the Win7 system eventually errors out with a message about the server not being found. That certainly strongly suggests that this is a firewall issue, and that kind of makes sense. The firewall may not have been all that picky on XP, which might be why I have never had any issues connecting to that system. In fact, I may not have a firewall on that system, since it can't connect to the internet. Furthermore, the firewall in question is the Win8 system, as it makes no difference whether or not the firewall on the Win7 system is active.
So, upon looking at the Win8 firewall settings, I see that there is a rule for allowing TCP connections on 1433, which is called SQL Server Access. Just to be doubly sure, I followed some steps from the interwebs and created a new rule that explicitly opens TCP on port 1433 (in case I overlooked a setting for the existing rule). That had no impact. My suspicion is that the port is wrong. The default instance of SQL Server Express, which this is, as far as I can tell, should be using port 1433. It is set to use dynamic ports, but that shouldn't matter, as it looks like the default instance won't really use some other port, but will use 1433.
Ok, after writing that, I decided to test my assumptions, and am now changing tack. When I set SQL Server to use a static port 1433, rather than assuming that the default instance would use that port anyways (as the documentation states), all is well. So, the default instance was NOT using the default port 1433. That bothers me a bit. My goal is that the app will have an installation that will, in some cases, install SQL Server Express. I'd like to automate this process as much as possible, but now I come to doubt that the default installation will use a port that will make the DB accessible over a LAN through the default settings of the firewalls. It looks like the installation might use a nearly random port, which the firewall won't allow, so all the other installations on the LAN will fail.
Is this a valid concern, or is my Win8 installation a bit unusual for not using port 1433?