I think it would be prudent to add a check to see what version of FreeTDS is being compiled against before adding these types, unless of course you have tested what happens when this is compiled against an older version of FreeTDS? At the very least some unit test coverage would be good :) Thanks!

I don't believe it matters if the code is compiled against an older FreeTDS version, since the new types will simply not be returned in that case. (Older FreeTDS versions, or newer ones with TDSVER set below 7.3, will return these date and type columns as strings.)

For test coverage, is it OK to write a test which won't run on older MSSQL versions?

Tests added - please have a look.

Hi, have you had time to look at the new merge request including tests?

@epa sorry, we don't have a lot of active developers right now. It may take some time for this to get reviewed and released.

Concerning testing for older versions of SQL Server. It would be better if the tests checked for the sql server version and used pytest.mark.skipif(...) to skip the test if the version is too old.

Yes, I'll add the skipif. Do you know how to test the version of SQL Server?

Something based on @@VERSION I'd guess: https://msdn.microsoft.com/en-us/library/ms177512.aspx

Something based on @@VERSION I'd guess: https://msdn.microsoft.com/en-us/library/ms177512.aspx

You could also check out SQLAlchemy code. I'd bet it has some code for getting the version out of MSSQL and comparing for testing/feature support.

Merged in 97129df

Thanks for merging this, sorry I didn't get around to making the tests conditional.