SQL Compare 13 not connecting to AG listener

elsimer

I have an AlwaysOn Availability Group listener (call it AG1) consisting of a primary (SQL01) and a secondary (SQL02). Using SQL authentication, I'm able to connect using SQL Compare 12.4.12.5042 with no difficulty. However, when I attempt to connect to AG1 using SQL Compare 13 (latest version attempted was 13.0.2.5109) I get an error:
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?

way0utwest

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

elsimer

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?!

way0utwest

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.