>>BTW, I did get an answer in my MSDN thread and yes, SQL Server driver is not supported by TLS 1.2
>>
>>
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/3bb679bd-65aa-4280-baec-12839b555e8e/old-sql-server-driver-is-it-still-supported-by-tls-12?forum=sqlsetupandupgrade>
>I still don't get it. If a customer currently uses a legacy ODBC driver for SQL Server, how would TLS mess this up?
It means that this driver is not going to be available when the client switches to this TLS 1.2 environment and so it's not going to be one of the choices when we create DSN to use with our application. As a result, our application (the way it currently connects to SQL Server) is not going to produce correct results when working with varchar(max) columns unless we do something in our code (say, use CAST(ourColumn as varchar(8000)) as ourColumn ) - obviously it's not a very good solution in our situation, but I don't see a better alternative (except for asking our client to get that Devart driver - who is going to pay then)?
If it's not broken, fix it until it is.
My Blog