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.

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

Theinitial 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 ishere.

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.

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 :)

/azp run

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.67%. Comparing base(d89372a) to head(aef1954).
Report is 230 commits behind head on main.

@@            Coverage Diff             @@##             main    #2839      +/-   ##==========================================+ Coverage   72.02%   72.67%   +0.65%==========================================  Files         299      285      -14       Lines       61430    59155    -2275     ==========================================- Hits        44246    42993    -1253+ Misses      17184    16162    -1022

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

@benrr101@mdaigle Can this be merged? That would help with#2953

just a heads up to people that this is now in the 6.1 milestone.
so i raised a discussion to talk about if this should be considered "breaking enough" to not be in a minor release

#3276