背景
我有访问SQL Server的遗留VB6代码。当SQL Server禁用TLS 1.0时，它会产生错误代码0x80004005，因为该代码仍然使用提供程序SQLOLEDB:
[DBNETLIB][ConnectionOpen(SECDoClientHandshake(((.]SSL安全错误
它没有明确使用TLS，但根据Microsoft文档，TLS始终用于凭据。
可能的解决方案
环顾四周，我发现微软发布了新的提供程序MSOLEDBSQL来代替SQLOLEDB。根据他们的文档：，MSOLEDBSQL支持TLS 1.2，并将不断更新
-
https://learn.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-服务器-ver15
-
https://learn.microsoft.com/en-us/archive/blogs/sqlnativeclient/released-microsoft-ole-db-driver-for-sql-server
在安装驱动程序并将(ADODB.Connection(连接字符串从更改后，我测试了MSOLEDBSQL
c.ConnectionString = "Provider=SQLOLEDB;Data Source=" & svr & ";Initial Catalog=" & db & ";User Id=" & u & ";Password=" & p & ";"
至：
c.ConnectionString = "Provider=MSOLEDBSQL;DataTypeCompatibility=80;Data Source=" & svr & ";Initial Catalog=" & db & ";User Id=" & u & ";Password=" & p & ";"
这就解决了问题。
问题
然而，我不确定，我正在做的是未来。
- 这是提供商MSOLEDBSQL真正的未来证明吗推荐另一个
- 我的VB6项目应该继续引用ADODB("msado28.tlb"Microsoft ActiveX Data Objects 2.8库(吗未来参考
- 例如：这将在未来与TLS 1.3一起工作吗
我希望尽可能少地更改
MDAC和VB6运行时是Windows组件，MSOLEDBSQL是最新的，并将继续维护。因此，这是您现在和将来运行这个遗留代码库的最佳组合。
未来的证明有点像"水晶球"；诸如此类的事情。我们可以在代码中做很多来让我们的生活更轻松，但归根结底，当我们使用第三方库时，我们不知道库什么时候会被弃用，它支持或不支持什么。
当涉及到我们作为开发人员拥有的代码时，当我们突然意识到有更好的方法(或者，事实上，只是进行代码重构，不想破坏我们的客户(时，我们可以编写抽象，并尽最大努力实现向后兼容。
对于第三方代码，这是不实用的。一天下来，你的数据库连接需要一个连接字符串和一个支持它的提供程序。预计未来可能会发生变化，你的路线图应该关注它。在某个时候，你必须执行更新，就像你刚刚做的那样。
您可以考虑将负责建立DB连接的代码重构到其自己的VB6 DLL中。这个DLL将管理连接字符串，包含必要的引用，并负责建立实际连接和返回正确的对象。
将此DLL设置为具有二进制兼容性。
在未来，如果连接细节发生变化，只有这一个DLL需要受到影响，从而最大限度地减少重新测试&重新部署。
此外，您还可以将连接字符串等数据存储在配置文件中。在只需要更改文本的有限情况下，可以想象，用户可以在得到良好指示的情况下自己更改文本。但除此之外，我认为配置文件增加的复杂性不值得；它还造成了更多的陷阱和失败点。