>>>>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?
>>
>>None of the drivers I currently have installed worked correctly for me using Antonio's test program (except for SQL Server driver). So, even if we don't use DSN, it's still a driver's problem.
>
>One possibility would be to create a workaround only for the memo fields: Select * should then be defining all fields individually and then CAST nVarchar(max) to Text.
>
>If there are too many queries, you could write a parser that interprets "MyTable.*" into separate fields. Get the field structure of the table "MyTable" and hunt for varchar(max). If found, replace the * with all fields and cast the varchar(max) to Text.

That's too many changes in too many places.