>>>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)?
What if you use DSN-less connection?
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
