Repository navigation
6.1.0: Taking a long time to connect #3523
Description
Describe the bug
When connecting to a remote server, version 6.1.0 is taking significantly longer than 6.0.2
using Microsoft.Data.SqlClient;
namespace SqlServerConnectTest
{
internal class Program
{
static void Main(string[] args)
{
var builder = new SqlConnectionStringBuilder();
builder.DataSource = "xxx";
builder.InitialCatalog = "xxx";
builder.UserID = "xxx";
builder. Password = "xxx";
builder.TrustServerCertificate = true;
builder.ApplicationName = "Connection test";
builder.ConnectTimeout = 30;
builder.Encrypt = true;
Console.WriteLine(builder.ConnectionString);
using (var cn = new SqlConnection(builder.ConnectionString))
{
try
{
var stopwatch = System.Diagnostics.Stopwatch.StartNew();
cn.Open();
stopwatch.Stop();
Console.WriteLine("Connection successful!");
Console.WriteLine($"Time taken to connect: {stopwatch.ElapsedMilliseconds} ms");
}
catch (SqlException ex)
{
Console.WriteLine($"SQL Error: {ex.Message}");
}
catch (Exception ex)
{
Console.WriteLine($"General Error: {ex.Message}");
}
}
}
}
}When running 6.0.2 on my system this took 948ms, in 6.1.0ms this takes 16494 ms. This is running in .NET 9 and the SQL Server is 2019.
Expected behavior
The connection should happen in roughly the same time on both versions
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
Wraith2 commentedon Jul 28, 2025
When I test against an azure server.
connecting to a local sql 2022 instance:
It might be worth checking your networking to see if there is some stall in name resolution. Try using the ip address and port directly instead of a name for example.
pietroserrano commentedon Jul 28, 2025
I have the same issue with SQL Server 2019 and .NET8.
When running 6.0.2 on my system this took 1040ms, in 6.1.0ms this takes 4494 ms.
chenhw commentedon Jul 29, 2025
No, it has nothing to do with this. I am using the server IP address in the LAN and it takes a long time to connect. It seems to be related to the version of SQL Server.
ErikEJ commentedon Jul 29, 2025
@chenhw Which server version?
Wraith2 commentedon Jul 29, 2025
OP says 2019, since I tested on 2022 and am fine it must be a 2019 problem. I don't have 2019 installed, I'd have to build a vm to test it.
chrishardstaff commentedon Jul 29, 2025
This was connecting with an IP address - I will set up a SQL2022 server to test.
chrishardstaff commentedon Jul 29, 2025
I'm getting the same results using a SQL2022 server - this is a remote server, I don't seem to have an issue when connecting to a local database server.
ErikEJ commentedon Jul 29, 2025
@chrishardstaff Do you connect via IP address or DNS name?
chrishardstaff commentedon Jul 29, 2025
@ErikEJ IP address
Wraith2 commentedon Jul 29, 2025
A thought. Is your client running on windows or linux? It changes what networking implementation the library uses. I tested on windows which has a native sni component but non-windows use the managed implmentation which can be forced on windows with an appcontext switch.
chrishardstaff commentedon Jul 29, 2025
I'm using windows
ErikEJ commentedon Jul 29, 2025
@chrishardstaff Could you share a (redacted) connection string?
40 remaining items
cxjke commentedon Dec 4, 2025
The issue is definitely real. We were forced to upgrade to 6.1.3 due to the .NET 10 EF Core libraries requiring >= 6.1.1. When connecting to an SQL Server 2019 or 2022 we experience the issue in our products.
Regarding your question @cheenamalhotra : Didn't #3804 basically confirm at least the 2016 part?
apoorvdeshmukh commentedon Jan 13, 2026
Hi, we finally have a setup which consistently reproduces this issue. We are actively working on the fix and will post updates once this is fixed. Thank you for the patience.
apoorvdeshmukh commentedon Feb 3, 2026
Can someone validate if the linked PR fixes the issue seen here?
Add gh CLI commands for issue milestone updates
Update analysis with current GitHub state - all PRs complete!