>>>>>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.

Maybe it's time to refactor? I pass all queries through a method that encapsulates data processing functionality. This way I can control the link between business code and data layer.

I also inherited a large codebase, and since it should live another 10 years I refactor whereever I can. Very old style VFP data access (inside form objects!). It's definitely worth it, because every hour you spend now gets paid back quadruple when time is most crucial: When the rewrite happens.