Comments
3 comments
-
Protocol. Only TCP works for the listener: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover#AGlisteners
-
way0utwest wrote: ยปProtocol. Only TCP works for the listener: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/listeners-client-connectivity-application-failover#AGlisteners
That makes sense, except I'm not specifying the connection method in either version. Is that an undocumented change in versions? To add to the mystery, this only appears to occur when using SQL authentication - if I'm using a Windows authentication connection (on our QA environment in this case) it connects to the listener in both versions?! -
If you have named pipes for the instance, then you'd connect that way to each node. The listener is what won't receive (or acknowledge) a named pipes connection. You can connect to SQL02 with named pipes, since it's responding to that protocol.
If you use Windows Auth, then I'm guessing it either defaults to TCP or falls back to TCP. Was looking for documentation on this, but didn't see it.
Add comment
Please sign in to leave a comment.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server).
I get the same message whether I enter the correct password or not, and it works without issue if I attempt to connect directly to the primary or secondary instead of the listener. Same behavior in SQL Data Compare 12/13.
We are running on SQL Server 2016 SP1 Enterprise edition.
Edit: Additionally, this only occurs under SQL Authentication. When using a trusted connection (Windows Authentication) both versions work without issue.
Any ideas?