[SOLVED] a *FUTUREPROOF* Project reference, to connect to SQL Server?

a *FUTUREPROOF* Project reference, to connect to SQL Server?

Background

i have legacy VB6 code that accesses SQL Server. it produces an error code 0x80004005 when TLS 1.0 is disabled for SQL Server, because the code still uses the provider SQLOLEDB:

[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.

it does not explicitly use TLS, but TLS is always used for credentials according to Microsoft documentation.

Possible Solution

after looking around i have found that Microsoft released the new provider MSOLEDBSQL as a replacement for SQLOLEDB. MSOLEDBSQL supports TLS 1.2 and that will be kept updated, according to their documentation:

i've tested MSOLEDBSQL after installing the drivers, and changing the (ADODB.Connection) connection string from:

c.ConnectionString = "Provider=SQLOLEDB;Data Source=" & svr & ";Initial Catalog=" & db & ";User Id=" & u & ";Password=" & p & ";"

to:

c.ConnectionString = "Provider=MSOLEDBSQL;DataTypeCompatibility=80;Data Source=" & svr & ";Initial Catalog=" & db & ";User Id=" & u & ";Password=" & p & ";"

and this fixes the problem.

Questions

however, i'm not sure, that what i'm doing is futureproof.

is this the provider MSOLEDBSQL indeed future proof, or would you recommend another one?
should my VB6 project keep referencing ADODB ("msado28.tlb" Microsoft ActiveX Data Objects 2.8 Library), or is there a more futureproof reference?
for example: would this work with TLS 1.3 in the future?

i would prefer to change as little as possible

Solution

MDAC and the VB6 runtime are Windows components, and MSOLEDBSQL is current, and will continue to be maintained. So that is your best combination for running this legacy codebase now and in the future.

Also SQLOLEDB was updated to support TLS 1.2. See Is sqloledb actually using MSOLEDBSQL on Windows Server 2019 So legacy codebases shouldn't be breaking on this any more.