Prevent connections to SQL 7.0 & 2000

[edwardneal]

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]

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]

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]

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]

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

[benrr101]

I'm sort of on the fence about this one. I can totally sympathize with @Wraith2 desire to leave support for old versions intact (eg, I work on a side project that targets a totally out-of-date version of nodejs so I can have the widest support I can). Yet, I also acknowledge that with corporate-sponsored open-source projects, we have to follow the compliance rules, and that generally means dropping support for EOL products. If there's no easy/approved way to test against EOL products, the code is going to wither, we'll get complaints about it not working, and won't be able to address the issues. So ultimately, I think we'll have to drop support for EOL SQL Server versions. As long as we don't pull old versions of MDS from Nuget, there'll still be an option for users of old versions of SQL Server.

[benrr101]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).