Share via

Conn Strings with DB Listeners seem to cause intermittent connect timeouts in Core apps. Why?

Robin McAninch 21 Reputation points
2025-07-18T14:08:18.6133333+00:00

Our DBAs have moved our SQL Server DBs to an always on architecture and replaced our connection strings that used to point directly to a server to one with a DBListener (looks like just another server name). We have not seen any issues with our Classic Framework Apps. Our Core apps range from getting this every time

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible.

to intermittently displaying this error (or a timeout error) and halting things. If we take the very same conn string and swap it to the primary server it works. We are having problems though because during any maintenance to the primary's box or blip with the connectivity to the primary and we get connection issues and stoppages. The answer on how to address is always use the listener which for a couple of our apps never works. The apps are Core 6 or higher, Entity Framework used but do use a couple of stored proc as well. Nothing special about the conn string (see below). We are seeing this on Core 8 apps too.

Server =[Name];Database=[Name];ID=[ID];[Password]=[Pwd];TrustServerCertificate=True

Any help would be appreciated.

SQL Server | Other

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Erland Sommarskog 128.6K Reputation points MVP Volunteer Moderator
    2025-07-18T20:28:34.7133333+00:00

    I don't think there is any fundamental difference between classic .Net and .NET core, although, I guess the newer app uses Microsoft.Data.SqlClient rather than System.Data.SqlClient. Which I don't think are radically different, but rather Microsoft.Data.SqlClient is a newer version.

    These sort of errors typically point at something in the network topology. Since it is intermittent, it can be difficult to track down. But rather than using only server name, using FQDN may work better.

    Other things to try is to increase the connection timeout and implement retries. That is, if you get the error you try again. This is good practice anyway, if you would happen to try to connect in the middle of a failover.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.