企业官网建设流程全解析

1. 项目概述：为什么VC++数据库编程在今天依然值得深挖？

最近在整理硬盘，翻出来一个十几年前用VC++ 6.0写的MIS系统源码。打开工程，看着那些熟悉的CDatabase、CRecordset类，还有满屏的ODBC API调用，一时间感慨万千。我试着在最新的Visual Studio 2022里编译了一下，你猜怎么着？除了几个不安全的字符串函数警告，核心的数据访问逻辑居然一次跑通，数据照常读写。这件事让我重新思考：在Python、Java、.NET Core大行其道的今天，为什么还要花时间去啃VC++数据库编程这块“老骨头”？

答案可能比你想象的更实际。首先，是存量系统的维护与升级。金融、电信、工业控制等领域，仍有大量核心业务系统运行在C++（尤其是VC++）构建的框架上。这些系统生命周期长，数据是命脉，直接重写成本高昂、风险巨大。掌握其数据库访问层的核心技术，是进行性能优化、安全加固、甚至向现代架构渐进式迁移的前提。其次，是对极致性能与资源控制的追求。当你需要处理海量实时交易数据、进行毫秒级响应的金融计算，或者在一个资源受限的嵌入式环境中直接操作硬件和数据库时，C++提供的零开销抽象和直接内存操作能力，是托管语言难以比拟的。最后，是技术理解的深度。数据库编程的本质是客户端与数据库服务之间的协议交互、数据缓冲与转换。通过VC++这种相对“底层”的方式去实践，你能更透彻地理解连接池、事务隔离、SQL注入防御等概念的实现机理，这种理解会反哺你在任何语言、任何框架下的数据库设计。

因此，这个“VC++数据库编程核心技术详解与实战”系列，并非怀旧，而是一次面向实战的深度回溯与重构。我会以现代开发环境（Visual Studio 2019/2022）为基准，剥离过时的、平台绑定的部分，聚焦于那些历久弥新的核心技术与设计模式。本分卷将作为基石，重点攻克VC++环境下数据库编程的统一访问接口、核心对象模型与高效数据交换机制。

2. 核心架构与数据访问技术选型

在VC++的世界里进行数据库编程，你首先面对的是一个“选择题”：用哪种技术栈来连接和操作数据库？这个选择直接决定了你后续开发的复杂度、性能上限和可维护性。我们先把主流选项摊开来看。

2.1 主流数据访问技术全景图与选型逻辑

VC++生态下的数据库访问技术，大致可以分为三代：

1. 原生API与驱动层：这是最直接的方式，包括ODBC API、OLE DB API以及各数据库厂商提供的原生C API（如MySQL C API、Oracle OCI）。这种方式性能最高，控制力最强，但代码最繁琐，需要开发者手动管理连接、语句句柄、绑定缓冲区、处理错误，堪称“硬核”模式。
2. 微软官方封装框架：为了简化开发，微软推出了MFC ODBC Classes（CDatabase,CRecordset）和MFC DAO Classes。它们将原生API封装成C++类，提供了面向对象的接口，大大提升了开发效率，是VC++ 6.0到VS 2008时代的主流选择。此外，ATL中也提供了OLE DB Consumer Templates，一种基于模板的、轻量级的OLE DB客户端封装。
3. 第三方跨平台库：为了追求跨平台能力和现代C++特性，社区涌现了像libpqxx（PostgreSQL）、MySQL Connector/C++、SOCI（Simple Oracle C++ Interface，现已支持多种数据库）这样的库。它们通常提供更符合现代C++习惯（如使用STL容器、异常、RAII）的接口。

注意：DAO（Data Access Objects）主要针对早期的Microsoft Jet数据库引擎（如Access），在现代开发中已基本被淘汰，本文将不展开讨论。

那么，如何选择？我的实战建议基于以下几个维度：

• 项目类型与数据库：如果你维护或开发一个紧耦合Windows平台、且使用SQL Server的MFC应用程序，MFC ODBC仍是快速上手的合理选择，因为它与MFC文档视图框架集成度好。如果是全新的、可能涉及多数据库或跨平台的项目，应优先考虑ODBC API（通用性强）或第三方库如SOCI。
• 性能与控制力：对性能有极端要求，或需要精细控制每一轮数据交换（如批量插入、流式读取大字段），原生ODBC API或OLE DB API是终极答案。MFC ODBC在易用性和性能间取得了较好平衡，但会有一定开销。
• 学习成本与团队技能：MFC ODBC概念相对简单，易于理解，适合快速产出。原生API和现代第三方库学习曲线更陡，但带来的技术深度和灵活性也更高。

在本系列中，为了全面覆盖核心技术原理，我将采取一种“由浅入深、对比讲解”的策略。我们会从最经典、应用最广泛的MFC ODBC开始，因为它完美体现了VC++数据库编程的经典对象模型。然后，我们会深入到其底层——ODBC API，揭示封装背后的真相。最后，会探讨OLE DB的差异与适用场景，并简要介绍现代替代方案如SOCI。这样，无论你面对何种场景，都能知其然，并知其所以然。

2.2 ODBC：跨数据库的统一接口基石

无论你最终使用哪一层封装，理解ODBC（Open Database Connectivity）都是至关重要的。它不是某个具体的驱动或库，而是一个标准化的调用层接口（CLI）规范。

你可以把ODBC想象成数据库世界的“USB标准”。你的应用程序（主机）有一个统一的USB接口（ODBC API），各种数据库（设备）则提供自己的USB驱动程序（ODBC Driver）。只要驱动程序符合标准，你的程序就能用同一套“插拔”方法（API调用）来使用它们。这解决了数据库编程中最头疼的“异构”问题。

ODBC架构的核心是驱动程序管理器（Driver Manager）和驱动程序（Driver）。你的应用程序调用统一的ODBC API（如SQLConnect,SQLExecDirect），驱动程序管理器负责加载正确的驱动程序，并将调用传递给它。驱动程序则将标准的SQL语法（可能需做细微转换）和API调用翻译成特定数据库能理解的“方言”和协议。

在VC++中，使用ODBC需要：

1. 在目标机器上配置好数据源（DSN），可以是系统DSN或用户DSN，它包含了数据库类型、地址、凭证等信息。
2. 在代码中引入<sql.h>,<sqlext.h>等头文件，并链接odbc32.lib。
3. 遵循标准的“获取环境句柄→获取连接句柄→连接→执行→处理结果→释放”流程。

虽然直接使用API繁琐，但理解这个流程是理解所有上层封装的基础。MFC的CDatabase类本质上就是对一个ODBC连接句柄（HDBC）及其相关操作的封装。

3. MFC ODBC编程核心类深度解析

MFC ODBC类库是VC++数据库编程的“经典皮肤”。它通过几个核心类，将ODBC的面向过程API转换成了面向对象的模型，极大地简化了开发。我们来深入拆解这几个类的内部机理与实战用法。

3.1 CDatabase：数据库连接的指挥官

CDatabase对象代表了一个到数据源的物理连接。你可以把它理解为一个连接池中的单个连接（虽然早期MFC本身不提供连接池，但CDatabase对象管理了连接的生命周期）。

核心方法与生命周期：

1. Open/OpenEx：建立连接的关键。我强烈推荐使用OpenEx，因为它参数更清晰。

   CDatabase db; CString strConnection = _T("DSN=MyDataSource;UID=sa;PWD=123456;"); // 或者使用连接字符串 // CString strConnection = _T("Driver={SQL Server};Server=myServerAddress;Database=myDataBase;UID=sa;PWD=123456;"); try { if (!db.OpenEx(strConnection, CDatabase::useCursorLib | CDatabase::noOdbcDialog)) { AfxMessageBox(_T("数据库连接失败！")); return; } } catch (CDBException* e) { e->ReportError(); e->Delete(); return; }

   • CDatabase::noOdbcDialog标志非常重要，它阻止ODBC驱动程序管理器弹出图形化的登录对话框，这对于需要静默连接的服务端或后台程序是必须的。否则，在缺少DSN或凭证时，程序会挂起等待用户输入。
   • 连接字符串的构造是门学问。对于SQL Server，除了DSN方式，直接指定驱动和服务器地址更灵活。记得对密码等敏感信息进行适当处理，不要像示例中这样硬编码。

2. ExecuteSQL：用于执行不返回结果集的SQL语句，如INSERT,UPDATE,DELETE,CREATE TABLE等。

   try { db.ExecuteSQL(_T("UPDATE Employees SET Salary = Salary * 1.05 WHERE Dept = 'IT'")); } catch (CDBException* e) { // 处理异常，例如主键冲突、语法错误等 CString strError; strError.Format(_T("执行SQL失败！错误信息：%s"), e->m_strError); AfxMessageBox(strError); e->Delete(); }

   实操心得：对于批量数据操作，反复调用ExecuteSQL执行单条INSERT效率极低。更好的做法是构造批量INSERT语句（如INSERT INTO T VALUES (1), (2), (3)...），或者使用我们后面会讲到的参数化操作配合事务。

3. 事务处理：BeginTrans,CommitTrans,Rollback。这是保证数据一致性的关键。

   if (db.CanTransact()) { // 检查数据源是否支持事务 db.BeginTrans(); try { db.ExecuteSQL(_T("INSERT INTO Accounts (Id, Balance) VALUES (1001, 5000)")); db.ExecuteSQL(_T("UPDATE Accounts SET Balance = Balance - 1000 WHERE Id = 1002")); // 模拟一个可能失败的操作 // if (someCondition) AfxThrowDBException(...); db.CommitTrans(); AfxMessageBox(_T("转账成功！")); } catch (CDBException* e) { db.Rollback(); e->ReportError(); e->Delete(); AfxMessageBox(_T("操作失败，已回滚！")); } }

   关键点：务必确保BeginTrans和CommitTrans/Rollback成对出现，并且在异常处理中调用回滚。事务的范围应根据业务逻辑合理设定，不宜过大（长时间占用锁）也不宜过小（失去原子性意义）。

4. Close：在对象析构时会自动调用，但显式调用是个好习惯，特别是在连接可能重用的情况下。关闭连接会释放所有关联的CRecordset对象。

3.2 CRecordset：数据记录的抽象与绑定

CRecordset是MFC ODBC的精华所在，它代表了一个从数据源查询得到的结果集，或者是一个可更新的数据视图。其核心思想是记录字段交换（RFX），类似于MFC对话框的数据交换（DDX），实现了数据库字段与C++类成员变量之间的自动数据交换。

工作原理与派生类创建：

你通常需要为每张需要操作的表或每个复杂查询创建一个CRecordset的派生类。ClassWizard（或现代VS中的“添加类”向导）可以自动完成这个工作，但理解其生成代码至关重要。

假设有一张Employees表，包含EmpID(int),Name(varchar),Salary(decimal)字段。向导生成的派生类头文件大致如下：

class CEmployeeSet : public CRecordset { public: CEmployeeSet(CDatabase* pDatabase = NULL); DECLARE_DYNAMIC(CEmployeeSet) // 字段/参数数据 public: // 以下为字段数据成员，对应表中的列 int m_EmpID; CString m_Name; double m_Salary; // 注意：实际中decimal可能需用其他类型精确表示 // 以下为参数数据成员（用于参数化查询） CString m_strNameParam; // 重写 public: virtual CString GetDefaultConnect(); // 默认连接字符串 virtual CString GetDefaultSQL(); // 默认SQL语句 virtual void DoFieldExchange(CFieldExchange* pFX); // RFX实现 // 实现 #ifdef _DEBUG virtual void AssertValid() const; virtual void Dump(CDumpContext& dc) const; #endif };

对应的源文件关键部分：

CEmployeeSet::CEmployeeSet(CDatabase* pdb) : CRecordset(pdb) { m_EmpID = 0; m_Name = _T(""); m_Salary = 0.0; m_strNameParam = _T(""); m_nFields = 3; // 字段数 m_nParams = 1; // 参数数 m_nDefaultType = snapshot; // 或 dynaset } CString CEmployeeSet::GetDefaultSQL() { return _T("[Employees]"); // 默认查询整张表 } void CEmployeeSet::DoFieldExchange(CFieldExchange* pFX) { pFX->SetFieldType(CFieldExchange::outputColumn); RFX_Int(pFX, _T("[EmpID]"), m_EmpID); RFX_Text(pFX, _T("[Name]"), m_Name); RFX_Double(pFX, _T("[Salary]"), m_Salary); // 参数绑定 pFX->SetFieldType(CFieldExchange::param); RFX_Text(pFX, _T("NameParam"), m_strNameParam); // “NameParam”是SQL中的参数占位符名 }

DoFieldExchange是灵魂：这个函数在记录集需要从数据库读取数据到成员变量，或者将变量数据写回数据库时，被框架自动调用。RFX_系列宏完成了底层ODBC数据绑定（SQLBindCol）的工作。

记录集类型的选择：

• snapshot：静态快照。在Open时一次性将数据取到客户端内存。数据是静态的，看不到其他用户后续的修改。占用内存，但浏览性能稳定。
• dynaset：动态集。通过键集驱动游标实现。它缓存了能唯一标识记录的键值，当需要访问某条记录时，才根据键值去数据库取最新数据。因此能看到其他用户提交的更新和删除（但可能看不到新增，取决于驱动）。是平衡了实时性和性能的常用选择。
• forwardOnly：仅向前游标。效率最高，内存占用最小，但只能单向（从头到尾）遍历一次，且不支持Edit/Update。

避坑指南：对于大型结果集，绝对不要使用snapshot，可能导致客户端内存耗尽。优先考虑dynaset或forwardOnly。如果只需要遍历一次数据用于处理或导出，forwardOnly是最佳选择。

3.3 记录集的核心操作：遍历、增删改查

创建好派生类后，就可以进行各种数据操作了。

1. 查询与遍历：

CEmployeeSet rs(&db); // 传入CDatabase对象指针 try { // 打开记录集，即执行默认SQL（SELECT * FROM Employees） rs.Open(CRecordset::dynaset, NULL, CRecordset::readOnly); // 可以指定SQL，NULL表示用GetDefaultSQL // 或者使用参数化查询 // rs.m_strFilter = _T("[Name] LIKE ?"); // 设置过滤条件，?是参数占位符 // rs.m_strNameParam = _T("%张%"); // 给参数赋值 // rs.Open(CRecordset::snapshot); while (!rs.IsEOF()) { // 判断是否到达结果集末尾 // 此时，rs.m_EmpID, rs.m_Name等成员变量已经是当前记录的值 CString strInfo; strInfo.Format(_T("ID:%d, 姓名:%s, 薪水:%.2f"), rs.m_EmpID, rs.m_Name, rs.m_Salary); // 处理strInfo... TRACE(strInfo + _T("\n")); rs.MoveNext(); // 移动到下一条记录 } rs.Close(); } catch (CDBException* e) { e->ReportError(); e->Delete(); }

2. 新增记录：

if (rs.CanAppend()) { // 检查是否支持追加 rs.AddNew(); // 进入“添加新记录”模式 rs.m_EmpID = 1001; rs.m_Name = _T("张三"); rs.m_Salary = 8000.0; rs.Update(); // 将缓冲区数据提交到数据库，执行INSERT // Update()之后，记录集可能会自动Requery，取决于驱动和设置 }

3. 编辑当前记录：

if (!rs.IsEOF() && rs.CanUpdate()) { rs.Edit(); // 进入“编辑当前记录”模式 rs.m_Salary *= 1.1; // 给当前员工加薪10% rs.Update(); // 提交更新，执行UPDATE }

4. 删除当前记录：

if (!rs.IsEOF() && rs.CanUpdate()) { rs.Delete(); // 删除当前记录 // Delete()后，当前记录指针会失效，必须立即调用MoveNext()或Requery() rs.MoveNext(); if (rs.IsEOF()) { rs.MoveLast(); // 如果删除了最后一条，移到最后一条有效记录 } }

关键注意事项：

• AddNew/Edit后必须跟Update或CancelUpdate，否则会导致资源泄露和未定义行为。
• Delete后记录指针失效，必须立即移动指针，否则后续操作可能崩溃。
• 事务与记录集：CDatabase的事务操作对关联的记录集同样有效。在BeginTrans后进行的AddNew/Edit/Delete/Update，都会在事务提交后才真正生效。
• 参数化查询是防御SQL注入的基石：永远不要用字符串拼接的方式来构造m_strFilter！像上面示例那样使用?占位符和参数数据成员，可以让ODBC驱动进行安全的参数化处理，从根本上杜绝注入攻击。

4. 高效数据交换与高级技巧

掌握了基本操作后，要写出高效、健壮的程序，还需要深入一些高级主题。

4.1 记录字段交换（RFX）机制深度剖析

RFX不仅仅是简单的赋值。在DoFieldExchange函数中，根据pFX的操作类型，RFX宏的行为不同：

• CFieldExchange::outputColumn：绑定查询结果列到成员变量。在Open或Requery时，数据从数据库读出并填入变量；在Update时，变量值被写回数据库对应的列。
• CFieldExchange::param：绑定参数变量。在Open或Requery前，你需要设置好参数变量（如m_strNameParam），RFX会将这些值安全地传递给ODBC驱动，用于填充SQL语句中的?占位符。

处理BLOB（二进制大对象）数据：对于图像、长文本等字段，需要使用特殊的RFX函数。

// 在派生类中声明 CLongBinary m_Photo; // 在DoFieldExchange中绑定 pFX->SetFieldType(CFieldExchange::outputColumn); RFX_LongBinary(pFX, _T("[Photo]"), m_Photo);

CLongBinary内部管理着一块全局内存（HGLOBAL）。操作BLOB数据通常效率较低，因为数据需要在客户端和服务器之间完整传输。对于超大BLOB，应考虑使用ODBC API的SQLGetData分段读取，或让数据库仅存储文件路径。

4.2 批量操作与性能优化实战

1. 批量读取优化：

• 使用SetRowsetSize：默认情况下，CRecordset一次从驱动取一行数据。可以设置行集大小，实现批量提取，减少网络往返。

  rs.SetRowsetSize(25); // 设置为一次取25行 rs.Open(...); while (!rs.IsEOF()) { for (int row = 0; row < rs.GetRowsFetched(); row++) { // 通过rs.GetData(row)等方式访问行集内数据 // 注意：标准RFX绑定的是“当前行”，使用行集需要调用ODBC API的扩展函数，或使用`CRecordset::GetFieldValue` } rs.MoveNext(); // 这里会移动到下一个行集 }

  使用行集需要更复杂的代码来访问行集缓冲区，但能显著提升大数据量查询的性能。

• 只选择需要的列：避免SELECT *，在GetDefaultSQL中明确指定列名，或者使用m_strFilter和m_strSort进行过滤排序，将计算压力放在数据库端。

2. 批量写入优化：

• 事务封装：将多条AddNew/Update操作放在一个事务中，可以大幅减少日志写入和提交开销。

  db.BeginTrans(); for (int i = 0; i < 1000; i++) { rs.AddNew(); // ... 设置字段值 rs.Update(); } db.CommitTrans(); // 一次提交

• 使用直接SQL执行：对于超大批量数据导入（如从文件导入十万条记录），构造一个大的INSERT ... VALUES (...), (...), ...语句，或者使用数据库的批量导入工具（如SQL Server的bcp或BULK INSERT），然后通过CDatabase::ExecuteSQL执行，效率远高于循环调用AddNew/Update。

4.3 多线程环境下的安全访问

MFC ODBC类不是线程安全的。CDatabase和CRecordset对象不能在多个线程间共享。每个需要访问数据库的工作线程，都应该创建自己独立的CDatabase连接和CRecordset对象。

最佳实践：

1. 连接池模拟：在主线程或一个管理线程中，预先创建多个CDatabase对象并打开连接，放入一个线程安全的队列（如使用临界区或互斥量保护）。工作线程从队列中取用一个连接，用完后归还。这避免了频繁创建和销毁连接的开销。注意，这只是一个简单的模拟，真正的连接池更复杂（如处理超时、心跳检测）。
2. 线程局部存储：如果连接使用不频繁，也可以让每个线程在首次需要时创建自己的连接，并将其存储在TLS中。
3. 绝对禁止：将同一个CRecordset对象在A线程打开，在B线程中读取或移动指针，这必然导致崩溃或数据错乱。

5. 常见问题排查与调试技巧实录

即使理解了原理，在实际编码中依然会遇到各种“坑”。下面是我从大量项目中总结出的常见问题与解决方法。

5.1 连接与配置类问题

问题1：连接失败，错误信息模糊。

• 排查步骤：
  1. 检查DSN：首先确认ODBC数据源（DSN）配置是否正确。可以在系统的“ODBC数据源管理器”中测试连接。
  2. 使用完整连接字符串：尝试绕过DSN，在OpenEx中直接使用包含驱动、服务器、数据库名的完整连接字符串。这能排除DSN配置问题。
  3. 启用跟踪：在ODBC数据源管理器中，启用驱动程序管理器跟踪，然后运行你的程序。这会生成一个详细的日志文件（sql.log），记录所有ODBC调用，是定位连接问题的终极武器。
  4. 检查网络与防火墙：如果是远程数据库，确保网络通畅，数据库端口（如SQL Server的1433）在防火墙中已开放。
• 实战技巧：在catch (CDBException* e)块中，不仅输出e->m_strError，也输出e->m_strStateNativeOrigin，它包含了ODBC返回的SQLSTATE和原生错误码，对搜索解决方案更有帮助。

问题2：程序在其他电脑上运行提示“未找到数据源名称且未指定默认驱动程序”。

• 原因：目标机器上没有配置相同的系统DSN或用户DSN。
• 解决方案：
  1. 部署时配置DSN：编写安装脚本，使用SQLConfigDataSourceAPI或odbcconf.exe工具在目标机器上自动创建DSN。
  2. 使用无DSN连接：始终在代码中使用完整的、包含驱动名的连接字符串，这样只需确保目标机器安装了正确的ODBC驱动即可，无需配置DSN。这是更推荐的做法。

5.2 SQL执行与数据操作类问题

问题3：ExecuteSQL执行INSERT或UPDATE成功，但数据库里没数据。

• 原因：很可能忘记了提交事务！如果你在BeginTrans后执行了操作，但没有调用CommitTrans，那么所有修改都只在当前连接会话中可见，连接关闭后修改会丢失。
• 检查：确认代码中BeginTrans和CommitTrans/Rollback是成对出现的，并且在所有可能的分支（包括异常分支）都得到了正确处理。

问题4：CRecordset打开时非常慢，或者内存占用飙升。

• 原因：
  1. 使用了snapshot类型打开了一个巨大的表。
  2. SQL语句没有WHERE条件，查询了全表数据。
  3. 查询的表中包含BLOB字段，且被一次性全部取出。
• 优化：
  1. 改用dynaset或forwardOnly。
  2. 务必添加有效的m_strFilter（WHERE条件）和m_strSort（ORDER BY），利用数据库索引。
  3. 对于BLOB字段，考虑在GetDefaultSQL中不选择它，或者使用延迟加载（RFX_LongBinary的某些选项或ODBC API）。

问题5：中文字段插入后变成乱码。

• 原因：字符集不匹配。数据库字段是UTF-8或GBK，而程序以ANSI（本地代码页）方式发送。
• 解决方案：
  1. 统一使用Unicode：确保整个工程使用Unicode字符集（在项目属性中设置），CString实际是CStringW。这是治本之策。
  2. 检查连接字符串：对于MySQL ODBC驱动，可以在连接字符串中添加Charset=utf8。对于SQL Server，确保数据库的排序规则支持中文，连接字符串通常不需要特殊设置。
  3. 数据库端检查：确认数据库、表、字段的字符集编码设置正确。

5.3 资源管理与异常处理

问题6：程序运行一段时间后，出现内存泄漏或连接耗尽。

• 原因：CDatabase或CRecordset对象没有正确关闭。
• 黄金法则：
  • RAII包装：将CDatabase和CRecordset对象封装在智能指针或自定义的RAII类中，确保在作用域结束时自动调用Close。
  • 局部对象：尽可能在函数内部创建记录集对象，使其成为栈上对象，函数返回时自动析构。
  • 显式关闭：在try-catch块中，如果提前返回，确保在return前调用Close()。
  • 检查连接限制：数据库服务器对最大连接数有限制。确保你的程序在空闲时释放连接（关闭CDatabase），或者使用连接池管理有限数量的连接。

问题7：如何获取执行UPDATE或DELETE语句后影响的行数？

• 方法：CRecordset的GetRecordCount函数对于可更新的记录集返回的是“已访问过的记录数近似值”，并非SQL影响的行数。要获取准确的影响行数，需要在执行ExecuteSQL后，调用ODBC API函数SQLRowCount。

  db.ExecuteSQL(_T("DELETE FROM Logs WHERE CreateTime < DATEADD(day, -30, GETDATE())")); SQLLEN rowCount = 0; RETCODE ret = SQLRowCount(db.m_hstmt, &rowCount); // db.m_hstmt是内部的ODBC语句句柄 if (ret == SQL_SUCCESS || ret == SQL_SUCCESS_WITH_INFO) { TRACE(_T("删除了 %ld 条记录\n"), rowCount); }

  注意：m_hstmt是CDatabase的保护成员，你可能需要编写一个派生类来公开或访问它。这揭示了深入底层API有时是必要的。

5.4 调试与日志记录

启用ODBC跟踪：如前所述，这是诊断复杂ODBC问题的核武器。日志会记录每个API调用的参数和返回值。

在catch (CDBException* e)中记录详细信息：不要仅仅弹出一个消息框。将错误信息、SQLSTATE、发生错误的函数名（e->m_strError中可能包含）、以及当时的SQL语句（如果你保存了的话）记录到日志文件中。这对于离线分析生产环境问题至关重要。

使用TRACE宏输出调试信息：在Debug版本中，TRACE宏可以将信息输出到Visual Studio的输出窗口，方便跟踪程序流和数据。例如，在遍历记录集时TRACE出关键字段的值。

掌握了MFC ODBC这一套经典组合拳，你已经能够应对VC++环境下绝大多数常规的数据库开发任务。然而，这只是数据库编程的第一层。当你追求更高性能、更细粒度控制，或者需要脱离MFC框架时，就必须直面其下的ODBC API，甚至探索OLE DB和现代C++数据库库。在后续的分卷中，我们将剥开这层封装，深入ODBC API的编程模型，并对比分析不同技术路径的优劣，让你真正成为VC++数据库编程领域的掌控者。