*FUTUREPROOF* 项目参考，连接到 SQL 服务器？
a *FUTUREPROOF* Project reference, to connect to SQL Server?
背景
我有访问 SQL 服务器的遗留 VB6 代码。当为 SQL 服务器禁用 TLS 1.0 时，它会产生错误代码 0x80004005，因为代码仍然使用提供程序 SQLOLEDB:
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security
error.
它没有明确使用 TLS，但根据 Microsoft 文档，TLS 始终用于凭据。
可能的解决方案
环顾四周后，我发现微软发布了新的提供程序 MSOLEDBSQL 作为 SQLOLEDB 的替代品。 MSOLEDBSQL 支持 TLS 1.2 并且会根据他们的文档不断更新：
https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15
-
我在安装驱动程序并更改 (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 数据对象 2.8 库），还是有更多的
面向未来的参考资料？
- 例如：这会在未来与 TLS 1.3 一起使用吗？
我希望尽可能少的改变
面向未来有点像“Crystal 球”之类的东西。我们可以在代码中做 很多 来让我们的生活更轻松，但归根结底 - 当我们使用第 3 方库时 - 我们不知道什么时候会有一个库已弃用，它将支持或不支持什么。
当谈到我们作为开发人员拥有的代码时，当我们突然意识到有更好的方法时，我们可以编写抽象并尽最大努力能够向后兼容做事（或者，实际上，只是进行代码重构，不想破坏我们的客户）。
对于第三方代码，这是不切实际的。归根结底，您的数据库连接需要一个连接字符串和一个支持它的提供程序。预计未来可能会发生变化，您的路线图应该密切关注它。在某些时候，您必须执行更新，就像您刚刚所做的那样。
MDAC 和 VB6 运行时是 Windows 组件，MSOLEDBSQL 是最新的，并将继续维护。因此，这是现在和将来 运行 这个遗留代码库的最佳组合。
您可以考虑将负责建立数据库连接的代码重构到它自己的 VB6 DLL 中。此 DLL 将管理连接字符串，包含基本引用，并将负责建立实际连接并返回正确的对象。
设置此 DLL 具有二进制兼容性。
将来如果连接细节发生变化，只需要影响这个 DLL，最大限度地减少重新测试和重新部署。
此外，您可以将连接字符串等数据存储在配置文件中。在只有该文本需要更改的有限情况下，可以想象用户可以根据良好的指示自己进行更改。但除此之外，我认为增加配置文件的复杂性是不值得的；它还会造成更多的陷阱和失败点。
背景
我有访问 SQL 服务器的遗留 VB6 代码。当为 SQL 服务器禁用 TLS 1.0 时，它会产生错误代码 0x80004005，因为代码仍然使用提供程序 SQLOLEDB:
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.
它没有明确使用 TLS，但根据 Microsoft 文档，TLS 始终用于凭据。
可能的解决方案
环顾四周后，我发现微软发布了新的提供程序 MSOLEDBSQL 作为 SQLOLEDB 的替代品。 MSOLEDBSQL 支持 TLS 1.2 并且会根据他们的文档不断更新：
https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15
我在安装驱动程序并更改 (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 数据对象 2.8 库），还是有更多的 面向未来的参考资料？
- 例如：这会在未来与 TLS 1.3 一起使用吗？
我希望尽可能少的改变
面向未来有点像“Crystal 球”之类的东西。我们可以在代码中做 很多 来让我们的生活更轻松，但归根结底 - 当我们使用第 3 方库时 - 我们不知道什么时候会有一个库已弃用，它将支持或不支持什么。
当谈到我们作为开发人员拥有的代码时，当我们突然意识到有更好的方法时，我们可以编写抽象并尽最大努力能够向后兼容做事（或者，实际上，只是进行代码重构，不想破坏我们的客户）。
对于第三方代码，这是不切实际的。归根结底，您的数据库连接需要一个连接字符串和一个支持它的提供程序。预计未来可能会发生变化，您的路线图应该密切关注它。在某些时候，您必须执行更新，就像您刚刚所做的那样。
MDAC 和 VB6 运行时是 Windows 组件，MSOLEDBSQL 是最新的，并将继续维护。因此，这是现在和将来 运行 这个遗留代码库的最佳组合。
您可以考虑将负责建立数据库连接的代码重构到它自己的 VB6 DLL 中。此 DLL 将管理连接字符串，包含基本引用，并将负责建立实际连接并返回正确的对象。
设置此 DLL 具有二进制兼容性。
将来如果连接细节发生变化，只需要影响这个 DLL，最大限度地减少重新测试和重新部署。
此外，您可以将连接字符串等数据存储在配置文件中。在只有该文本需要更改的有限情况下，可以想象用户可以根据良好的指示自己进行更改。但除此之外，我认为增加配置文件的复杂性是不值得的；它还会造成更多的陷阱和失败点。