SQL Server 2012通过本机C++；（无ATL）来自Windows的首选访问方法 我有一个本地C++应用程序，它运行在Windows 64下，不使用ATL（也不会）。我希望能够通过网络从应用程序连接到SQL Server 2012

我有以下要求：

• 性能是关键

<> > C++只插入记录（例如调用存储的进程），没有其他（没有选择、删除或更新）。
• 记录插入应该是非阻塞（异步）的

我将选择范围缩小到OLEDB和ODBC，因为它们满足上述条件。然而，似乎互联网上有大量关于使用什么的自相矛盾的建议。示例：

• “如果您可以选择使用ODBC或OLE DB访问SQL Server数据库，请选择OLE DB，因为它通常更快。[7.0，2000，2005]更新2-20-2006”来源：

• “OLE DB已弃用”来源：

• “避免将OLE DB用于新的SQL Server应用程序开发。请更新技术路线图，以便将使用SQLNCLI、SQLNCLI10、SQLNCLI11或SQLOLEDB OLE DB提供程序的现有SQL Server应用程序迁移到SQL Server本机客户端ODBC驱动程序。”来源：但是SQLNCLI11是基于MSDN的SQL Server本机客户端ODBC驱动程序：那么，这是博客中的一个输入错误吗

---

我真的很困惑，想根据我的标准对访问SQL Server的最佳技术发表更多意见。

OleDB和ODBC都使用SQLNCLI。请参阅下表，了解Sqlncli.dll/Sqlncli10.dll/Sqlncli11.dll是ODBC和OleDB的驱动程序

如果你看一下，你会发现ODBC和OleDB都是最新的并且受支持的。什么是SQLOLEDB和SQLODBC，它们是OleDB和ODBC的旧MDAC SQL Server驱动器（即sqlsrv32.dll和SQLOLEDB.dll）。它们都有升级路径和建议，请参阅

因此，结论是您可以安全地继续使用ODBC和OleDB，只需确保使用基于SLNCLI的现代驱动程序，而不是旧的、不推荐使用的MDAC驱动程序

---

使用不推荐使用的驱动程序的主要风险是缺乏对新数据类型的支持（如地理、层次、日期时间2等）。

我多年前体验过OleDB（使用ATL）和ODBC（使用MFC）

但是接口很少成为瓶颈，通常插入/更新占主导地位（实际上，我使用bulkcopy+存储过程执行了大型插入/更新）

---

无论如何，我建议使用一种中间的（第三种）方式：使C++ +ODBC可忍受。

认为仅仅因为某些东西被弃用并不意味着你不能使用它。在世界各地早已过时的操作系统上，都有不受支持的SQL Server 2000设备，即使它们运行的许多软件早已被弃用，这些应用程序仍在继续运行。我不是说这是一个使用旧垃圾的理由，而是因为你选择了C++，可能还有更糟糕的事情。本地客户端安装包括OLE DB提供程序（SqliNclixx）和ODBC驱动程序。SQLNCLI11是一个OLE DB提供程序，它不是“SQL Server本机客户端ODBC驱动程序”。只需使用ODBC。@wqw这是您所说内容的一个使用示例吗？尽管它包含sqlncli.h？我看过了，但它使用的是STD模板，我更喜欢ODBC函数的C风格方法。我不关心代码的复杂性，因为它只是插入（和一个插入语句）。您标记了C++的问题，然后我建议了我知道的最好的接口。但是“de gustibus…”你在这一点上是对的，我在这一点上不是很精确，因为我的重点是提到的三个标准（性能、插入和异步）。无论如何，OTL不能与ODBC C接口相比，它更接近于高级别，但不是很接近。SQLNCLI也被弃用，继续前进。ODBC的替代品是“Windows上SQL Server的Microsoft ODBC驱动程序11”。没有OLEDB替代品。从您自己的链接：“在SQL Server 2012之后，SQL Server本机客户端OLE DB提供程序将不再包含在SQL Server本机客户端中。”同时，OLE DB驱动程序已被取消使用。所以目前微软提供OLEDB和ODBC。