ODBC连接字符串中Driver字段必须严格匹配系统注册的驱动名，如{ODBC Driver 17 for SQL Server}，否则报IM002错误；SQLAllocHandle失败多因进程位数（x86/x64）与odbcad32.exe版本不一致；SQLExecDirect出错须调用SQLGetDiagRec获取真实SQLSTATE和原生错误码；宽字符需显式启用Unicode支持，推荐使用SQLDriverConnectW及SQL_C_WCHAR绑定。
ODBC连接字符串里Driver字段必须严格匹配系统已安装驱动名
Windows上ODBC驱动名不是随便写的，比如想连SQL Server，Driver={SQL Server}在旧系统可能有效，但新系统（尤其是64位平台）实际注册的是Driver={ODBC Driver 17 for SQL Server}或Driver={ODBC Driver 18 for SQL Server}。用错名字会导致SQLDriverConnect返回IM002错误（“数据源名称未找到”）。建议用odbcad32.exe（控制面板→管理工具→ODBC数据源）查看“驱动程序”页签下的**精确名称**，注意括号和空格都不能少。
SQLAllocHandle失败大概率是环境位数不匹配
C++程序编译为x64却调用32位ODBC API，或反过来，都会让SQLAllocHandle直接返回SQL_INVALID_HANDLE。这不是代码写错了，而是进程架构和ODBC驱动管理器不一致。检查点有三个：
• 项目配置的平台（x86 vs x64）是否与你用odbcad32.exe查看驱动时运行的版本一致（32位odbcad32.exe在SysWOW64目录下，64位在System32）；
• #include <sql.h></sql.h>和<sqlext.h></sqlext.h>来自哪个SDK（确保和目标平台匹配）；
• 链接的odbc32.lib（x86）或odbccp32.lib（x64）是否正确——其实更稳妥的做法是动态加载SQLAllocHandle地址，避免静态链接歧义。
SQLExecDirect执行失败时，先查SQLSTATE再看SQLGetDiagRec
ODBC错误信息藏得深，只看SQLExecDirect返回值（如SQL_ERROR）没用。必须调用SQLGetDiagRec才能拿到真实错误：
• 第一个参数传SQL_HANDLE_STMT（不是SQL_HANDLE_DBC）；
• pfNativeError参数常被忽略，但它能给出数据库原生错误码（比如SQL Server的18456登录失败）；
• szSqlState长度至少为6字节（含终止符），填SQL_SQLSTATE_SIZE最安全；
• 常见陷阱：忘记在调用前用SQLFreeHandle清理上一次失败的语句句柄，导致后续SQLGetDiagRec返回乱码。
宽字符支持要主动启用，别依赖默认
如果数据库中有中文或emoji，用SQLCHAR传参大概率乱码。ODBC默认走ANSI路径，必须显式切换到Unicode：
• 连接字符串末尾加;Unicode=Yes（部分驱动支持，非标准但常用）；
• 更可靠的是用SQLDriverConnectW代替SQLDriverConnect，所有参数传SQLWCHAR*；
• 绑定参数时，用SQLBindParameter指定SQL_C_WCHAR和SQL_WVARCHAR；
• 注意：SQLWCHAR在Windows上是UTF-16，但某些驱动（如MySQL ODBC）对BOM敏感，开头带0xFEFF可能报错，建议用std::wstring构造后手动去掉首BOM。
立即学习“C++免费学习笔记（深入）”；
ODBC真正难的不是语法，是驱动注册表项、进程位数、字符编码这三层嵌套的隐性约束。哪怕连接字符串一字不差，只要其中一层错位，错误提示就只会冷冰冰地告诉你“无法连接”。
