Drop support for SQL server < 2017

[andyundso]

With this PR, we drop support for SQL Server < 2017.

The first part of the PR extends our existing Continous Integration to run tests against each combination of our supported Ruby versions and SQL Server 2017, 2019 and 2022 on both Linux and Windows.

I therefore would also suggest we remove support for anything below SQL Server 2017. Technically, people could still use tiny_tds against these older versions as long as they compile FreeTDS with TDS v7.3 or v7.4. And SQL Server 2008 is the earliest version that supports v7.3. However, I think it's good if we can test our software against what we support, and if 2017 is the earliest version where I can do this, then I'm happy to drop support for anything older. Only v2014 and v2016 are still covered by extended maintenance of Microsoft, we can expect most people upgraded at this point.

The second part of this PR is code removal. First of all, there was not any new data type or changes to them since SQL Server 2016, so I removed all the different schemas. I also removed two ifdef from the C code.

• DBSETUTF16 is there to detect if UTF-16 is supported by FreeTDS. This was introduced in v1.0, and I think we can expect everybody to run a newer version than v1.0.
• DBVERSION_73 detects if FreeTDS supports TDS v7.3, which is the case since v0.95. We mainly used it to cast the different date and time formats in these newer TDS versions. Again, I think it's reasonable to expect that everybody runs a newer version than v0.95.

People should get a compile error when trying to build tiny_tds now with an version older than v1.0 when building tiny_tds.

Two things I'd like to tackle in the future.

• I would like to run the test suite against Azure, since this is a test case where I see it will be hard to test it in the pipeline, but testing it manually from time to time should be fine.
• Setup MSSQL with encryption in the pipeline. Maybe just for one version (2022?) to also verify that our OpenSSL setup works.

[aharpervc]

Awesome, love all the deletions! I left a few minor line comments then LGTM

[aharpervc]

This can be rephrased/removed now that we're using the official image

[andyundso]

addressed with 17d0fea.

[aharpervc]

Is now the time to also bump the default version here? (after reading the rest of the PR), eh probably fine as is

[andyundso]

I see it the same way: We can bump it again once it's time to drop 2017 support :)

[aharpervc]

I recommend keeping the checksum, even if you want to also introduce the mssql version to the key

[andyundso]

added with aa830a4.

[aharpervc]

Can you fold this sentence into the above paragraph? If it's the default then no config file is required to get utf 16 working

[andyundso]

addressed with bf00434.

[aharpervc]

Should this be 2017 since it's basically the new default min version?

[andyundso]

addressed with 6684afb.

[aharpervc]

If I'm reading this correctly, TDS 7.3 is the new min version, correct? Any benefit to a reverse check somewhere (not necessarily here) that raises an exception if the version is < 7.3?

[andyundso]

I added two checks with cfe7d92:

1. If the DBVERSION_73 symbol is not defined, the user is using a very old FreeTDS version and should be unable to compile the code.
2. Once we established the connection, we can ask about the tds version used to connect. There I added an exception if using a TDS version older than 7.3. This worked quite well.

$ TDSVER=7.2 bundle exec rake test
Basic query and result::with multiple result sets::using :empty_sets TRUE#test_0001_handles a basic empty result set:
TinyTds::Error: connecting with a TDS version older than 7.3!
    /home/andy/dev/andyundso/tiny_tds/lib/tiny_tds/client.rb:60:in `connect'

[aharpervc]

Similar question about saying 2016 in this file if the new min version is 2017

[andyundso]

addressed with 6684afb.

[aharpervc]

Will 1.0 actually work or is 1.1 the new safe minimum?

[andyundso]

I reverted locally to an older FreeTDS version we once shipped, 1.00.27:

diff --git a/ext/tiny_tds/extconsts.rb b/ext/tiny_tds/extconsts.rb
index 0a362fa..65d3773 100644
--- a/ext/tiny_tds/extconsts.rb
+++ b/ext/tiny_tds/extconsts.rb
@@ -2,8 +2,14 @@
 ICONV_VERSION = ENV['TINYTDS_ICONV_VERSION'] || "1.15"
 ICONV_SOURCE_URI = "http://ftp.gnu.org/pub/gnu/libiconv/libiconv-#{ICONV_VERSION}.tar.gz"
 
-OPENSSL_VERSION = ENV['TINYTDS_OPENSSL_VERSION'] || '1.1.1s'
+OPENSSL_VERSION = ENV['TINYTDS_OPENSSL_VERSION'] || '1.1.0j'
 OPENSSL_SOURCE_URI = "https://www.openssl.org/source/openssl-#{OPENSSL_VERSION}.tar.gz"
 
-FREETDS_VERSION = ENV['TINYTDS_FREETDS_VERSION'] || '1.1.24'
-FREETDS_SOURCE_URI = "http://www.freetds.org/files/stable/freetds-#{FREETDS_VERSION}.tar.bz2"
+FREETDS_VERSION = ENV['TINYTDS_FREETDS_VERSION'] || "1.00.27"
+FREETDS_VERSION_INFO = Hash.new { |h,k|
+  h[k] = {files: "http://www.freetds.org/files/stable/freetds-#{k}.tar.bz2"}
+}
+FREETDS_VERSION_INFO['1.00'] = {files: 'http://www.freetds.org/files/stable/freetds-1.00.tar.bz2'}
+FREETDS_VERSION_INFO['0.99'] = {files: 'http://www.freetds.org/files/current/freetds-dev.0.99.678.tar.gz'}
+FREETDS_VERSION_INFO['0.95'] = {files: 'http://www.freetds.org/files/stable/freetds-0.95.92.tar.gz'}
+FREETDS_SOURCE_URI = FREETDS_VERSION_INFO[FREETDS_VERSION][:files]

I had three test errors locally with network connection failures through Toxiproxy, but I also encounter these with the newer FreeTDS version. So I would say v1.0 is safe to say we can support.

[andyundso]

@aharpervc would you mind to re-review. besides implementing your feedback, I also optimised two things in the C.

[aharpervc]

LGTM

[andyundso]

@aharpervc I ran out of free credits on CircleCI thanks to this PR. It is somewhat expected since this PR adds many more parallel pipeline runs, but still happened faster than I anticipated.

I see two options:

1. Revert most changes here in regards to the pipeline, means we continue to only test on MSSQL 2017.
2. Move to GitHub Actions since you have unlimited runtime when the repository is public. I already built of copy of our pipeline last year in a fork of ours, so most work is already done, just needs to updated again (drop the older Ruby builds, add 3.3, update rake-compiler-dock).

I personally grew very found of GitHub Actions, mainly because of the actions. At work, we are moving all projects over from Semaphore CI. But it was you in collaboration with @bryanwieg who got the CircleCI pipeline up-and-running, so I would leave the choice going forward to you.

[bryanwieg]

I would not take it personally at all if the pipeline was changed to GitHub. Even when I worked on it so long ago, trying to manage the CircleCI credits was a constant battle. Besides being free, GitLab is a widely used integrated and supported solution, whereas I’ve never again used CircleCI outside this project.

[aharpervc]

But it was you in collaboration with @bryanwieg who got the CircleCI pipeline up-and-running, so I would leave the choice going forward to you.

Also fine with me to set up a PR to switch to GH Actions, for whoever has time to work on it. Not sure if you're saying it needs to be a prerequisite for this PR though, I'd personally prefer that be separate work. But that'd also give us all a chance to try and imagine a CI workflow that's less complicated, if such a thing is possible.

[andyundso]

Not sure if you're saying it needs to be a prerequisite for this PR though, I'd personally prefer that be separate work

Absolutely not, I just can't re-run the one failing test (downloading and installing Ruby on Windows timed out) since I do not have any credits left. But I would go ahead and merge this PR before building the GitHub Actions part next.