search

dotnet / SqlClient

Microsoft.Data.SqlClient provides database connectivity to SQL Server for .NET applications.
MIT License
857 stars 286 forks source link

Prevent connections to SQL 7.0 & 2000 #2839

Open edwardneal opened 2 months ago

edwardneal commented 2 months ago

This prevents connections from the .NET Framework build of Microsoft.Data.SqlClient to SQL Server 7.0 and SQL Server 2000 (RTM & SP1.) Doing so aligns the .NET Framework build with the .NET Core build on all OSes: the library will no longer be able to connect to any version of SQL Server prior to 2005.

I've also included a test to verify failed/successful connections to different simulated server versions.

There's a bit of SQL Server 2000-specific code in the .NET Framework project, and this hasn't been removed yet. Since this could be considered a breaking change, I'm aiming simply to implement the functional block for the v6 release, ready for the then-redundant paths to be removed later.

Wraith2 commented 2 months ago

While those systems aren't supported is there a reason to remove the ability to use it? I've encountered a live sql 2000 server recently and while i wasn't programming against it others may be, for example sql management studio will lose the ability to connect.

edwardneal commented 2 months ago

That's a completely fair point, and part of the reason I raised the PR is to talk that through. As we start to merge the more sensitive classes relating to connections and transactions, there are code paths which we handle differently for downlevel clients. The options for this are:

  1. Implement the same code paths in the .NET Core library, and test them with a SQL 2000 system. I'm not opposed to doing this if it's technically practical for the CI to run those tests, but at that point we've effectively relaxed the minimum version from SQL 2014 to SQL 2000
  2. Lock them behind conditional compilation - which isn't the worst thing in the world, but I'd prefer to only do this for cases where .NET Core/Framework have different APIs for the same operation, rather than to maintain a codebase which has different capabilities based on how it's targeted
  3. Remove SQL 2000 & SQL 7.0 support from the .NET Framework library

The initial feedback was:

There's no reason that main needs to work on anything older than 2014. Scratch that. 2016, since 2014 EOLs July 9. Users who are running EOL servers can use old clients.

I've seen enough SQL 2008/R2/2012 servers recently to err on the side of caution when thinking about enforcing a minimum version of SQL 2014 across the board, but a baseline of SQL 2005 seems fair enough. I'm only proposing the removal of SQL 2000 support from the .NET Framework version, which still has the supported alternative of System.Data.SqlClient; the .NET Core library has never supported it.

As far as SSMS support goes: I expect that people who still need to connect to downlevel versions of SQL Server would need an older version of SSMS.

To put some context to the downstream changes this'll enable, I've got a second PR after this which covers the actual code changes. The diff of this is here.

David-Engel commented 2 months ago

We aren't going to test EOL SQL Server versions in CI. Security compliance rules that out.

I'm all for cleaning up old code. We should not connect to anything prior to TDS 7.4.

CC: @saurabh500 and @cheenamalhotra as an FYI.

MichelZ commented 1 week ago

Removing SQL 7.0/2000 support from TdsParser would remove quite a few differences between netcore and netfx and make merging the classes much easier. I hope this gets in soon :)