C语言连接SQL Server实战：ODBC接口完整教程-拓冰网站定制

最近在做Win32程序改造，甲方要求底层逻辑继续用C语言，但数据汇总必须落到SQL Server里。翻了半天资料，发现聊C语言连数据库的帖子要么太老，要么是拿C++凑数，真正在VS里用C语言操作SQL Server的完整流程反而不多。这篇文章就把我这段时间踩过的坑、验证过的代码，以及环境选型的思路一次性写清楚，给同样需要在C项目里加数据库能力的读者一个可直接抄作业的参考。

整个方案适合这样几类读者：C语言基础已经学过结构体、指针，想搞明白程序怎么跟数据库打交道的学生；手上有老C模块要加数据上报功能的开发者；还有做嵌入式或上位机、数据库恰好选型SQL Server的工程师。如果你只是想用Python或Java连库，那这篇文章帮不上忙，但如果你必须在C语法和VS环境下完成这件事，下面的内容会对你有用。

1. 为什么用C语言直接操作SQL Server

1.1 这个组合解决的真实问题

C语言操作数据库，在不少人看来属于“上古操作”，觉得应该用ORM或者脚本语言。但实际项目里，很多Windows桌面工具、工业控制上位机、设备配置程序本身就是C/C++写的。这些程序往往跑在内网机器上，部署环境固定，引入Java或Python运行时反而增加维护成本。把SQL Server的读写能力直接集成到C程序里，既不需要额外启一堆服务，也不用跨进程做数据导入导出，程序本身就把数据写进数据库，逻辑闭环。

SQL Server在这个组合里的角色也很简单：它充当可靠的数据存储端。选SQL Server而不是MySQL或SQLite，通常是因为企业内部已经有一套SQL Server基础设施，运维经验、备份策略、权限体系都是现成的。C程序只需要通过ODBC接口把数据送进去，剩下的高可用、灾备、权限管理交给数据库自身。

1.2 选型对比：为什么是ODBC而不是其他方式

Windows平台上C语言访问SQL Server，主流方案有三个：官方ODBC API、ADO（通过COM封装）、以及第三方库。ADO在C语言里用起来要维护COM接口指针，代码繁琐且纯C环境支持一般；第三方库（比如某些开源封装）问题在于版本更新节奏跟不SQL Server的迭代，遇到新版TLS加密策略就容易踩坑。而ODBC是微软主推的标准数据库访问接口，C语言可以直接调用API函数，SQL Server的ODBC驱动也一直在维护，跨版本兼容性最好。

还有一点容易被忽略：ODBC是标准接口，这意味着代码写好后，如果哪天数据库从SQL Server换成别的支持ODBC的数据库，需要改动的只是连接字符串和少数几个SQL方言。虽然现实里很少真去切换，但这种可移植性在方案评审时是个加分项。

2. 环境准备：VS与SQL Server的安装搭配

2.1 Visual Studio怎么选版本和组件

Visual Studio Community版本对个人开发者和小团队免费，功能上足够开发C程序。安装时要注意工作负载别选错：必须勾选“使用C++的桌面开发”。很多人以为C语言支持包含在“.NET桌面开发”或“通用Windows平台开发”里，实际上不是。C/C++编译器、Windows SDK、调试器都归类在C++桌面开发这个工作负载下。

不需要额外装“单个组件”，默认带的MSVC编译器和Windows SDK已经够用。版本的话，VS2022是目前主力，但如果你所在团队还在用VS2019，也完全没有问题，ODBC API从很老的VS版本至今接口都是稳定的。唯一要注意的是生成配置里平台工具集默认是v143（VS2022），老项目打开时可能会提示升级，升级一次就好。

2.2 SQL Server用哪个版本最合适

SQL Server 2022 Developer版是免费且功能完整的，适合开发测试，唯一限制是不能用于生产环境。如果项目对版本体积敏感，可以用SQL Server Express，Express有10GB数据库大小限制，但对多数上位机数据采集场景完全够用。个人不推荐一上来就装企业版，你大概率用不到那些高级功能，反而白白占用内存。

安装SQL Server实例时，有几个关键选项必须处理：

身份验证模式建议选“混合模式”，因为ODBC连接字符串里既可能用Windows身份验证，也可能用SQL账号登录。只用Windows身份验证在域环境方便，但到客户现场或跨机器调试时，SQL账号登录更省事。
设置sa密码时记得用强密码。很多人图省事设成123456，结果写连接字符串测试没问题，等安全扫描时被点名整改。
勾选“安装SSMS”（SQL Server Management Studio）。虽然也可以用命令行工具，但有图形界面建库建表、查数据，初期调试效率高不少。

SQL Server安装完成后，还要确认一个服务：SQL Server (MSSQLSERVER) 是否在Windows服务里运行。装好后默认启动类型是自动，但有些精简版环境会被改掉，程序连接不上时第一件事就是看服务状态。

2.3 建好测试库和测试表

环境装好后，先用SSMS建一个最小测试库。操作顺序是：登录后右键“数据库”节点新建数据库，比如叫TestDB；然后在TestDB下新建查询，执行一段建表脚本：

CREATE TABLE users ( id INT IDENTITY(1,1) PRIMARY KEY, username NVARCHAR(50) NOT NULL, age INT NULL );

为什么用NVARCHAR而不是VARCHAR？因为NVARCHAR按Unicode存储，C语言侧用宽字符绑定能直接处理中文，后面遇到的乱码问题会少很多。这张表结构虽然简单，但覆盖了字符串、整数、自增主键三要素，足够演示增删改查。

建好表后再插入几条测试数据，用SSMS或SQL语句都行。插入时只写username和age，主键自动生成：

INSERT INTO users(username, age) VALUES (N'张三', 25); INSERT INTO users(username, age) VALUES (N'李四', 30); INSERT INTO users(username, age) VALUES (N'王五', 28);

前额的N前缀表示Unicode字符串字面量。为什么要强调这个细节？因为如果表列是NVARCHAR，你插入的字符串字面量不带N，SQL Server会做一次隐式类型转换，虽然测试没问题，但在某些排序规则下会丢数据。

3. C语言连数据库的核心：ODBC接口

3.1 ODBC的角色和调用思路

ODBC（Open Database Connectivity）本质上是一套C语言API，由驱动管理器（odbc32.dll）加具体的数据库驱动组成。你写的代码统一调用ODBC接口，驱动管理器会把调用转发给SQL Server ODBC Driver。整个过程你不需要知道TCP协议细节，也不需要拼网络包，ODBC替你完成了底层通信。

用ODBC编程有一个固定套路，四步走：分配环境句柄、分配连接句柄、分配语句句柄、执行SQL并取结果。等到操作完，还要逆序释放句柄。这个套路乍看繁琐，但好处是生命周期非常清晰，句柄泄漏问题基本可以通过检查每一层是否释放来避免。

ODBC里大量使用句柄，你可以把它理解成一种“资源的钥匙”。环境句柄是全局资源；连接句柄对应一次数据库连接；语句句柄对应一条SQL执行上下文。C语言没有对象概念，但通过句柄，我们拿到了类似对象的资源管理能力。

3.2 连接字符串拆解

连接字符串是ODBC方案里最需要理解的部分。我第一次用的时候漏掉了版本号，折腾了很久。标准写法是这样：

"DRIVER={ODBC Driver 17 for SQL Server};" "SERVER=localhost;" "DATABASE=TestDB;" "UID=sa;" "PWD=YourStrongPassword;" "TrustServerCertificate=yes;"

DRIVER：指定驱动名。不同的SQL Server驱动版本名称不同，常见的有“SQL Server”、“ODBC Driver 13 for SQL Server”、“ODBC Driver 17 for SQL Server”、“ODBC Driver 18 for SQL Server”。建议装最新的ODBC Driver 18，因为它默认强制加密，安全性更好。但要注意，如果服务器端证书是自签名的，连接字符串里必须加TrustServerCertificate=yes才能连上。
SERVER：目标SQL Server实例。本机调试写localhost或127.0.0.1即可；如果SQL Server用了命名实例，写“计算机名\实例名”或“IP\实例名”。
DATABASE：默认连接的数据库。
UID和PWD：SQL验证方式的账号密码。
TrustServerCertificate：信任服务器证书。默认是no，但自签名证书环境下连不上，开发环境可以直接设置yes。

还有个参数Encrypt，ODBC 18里默认值是yes。如果不想开启加密，需要显式写Encrypt=no。但这里我要提一句：生产环境不建议关闭加密，本地测试可以，因为关闭后比较容易出安全审计问题。

3.3 头文件、链接库和第一个连接程序

工程里需要引入三个头文件：sql.h（基础定义）、sqlext.h（扩展API）、sqltypes.h（数据类型常量）。在VS工程里不需要手动配置库文件，只要代码里包含头文件，并且在项目属性里将“附加依赖项”加上odbc32.lib。更省事的方法是直接写一行预处理指令：

#pragma comment(lib, "odbc32.lib")

这样就免去了在IDE属性页里点来点去的麻烦。写代码时，工程文件后缀虽然是.c，但MSVC编译器会按C语法编译，只要注意一些C和C++的细节差异即可。

一个最小连接程序框架长这样：

#include <stdio.h> #include <sql.h> #include <sqlext.h> #pragma comment(lib, "odbc32.lib") void show_error(SQLSMALLINT handle_type, SQLHANDLE handle) { SQLSMALLINT i = 1; SQLRETURN ret; SQLCHAR sqlstate[6]; SQLINTEGER native_error; SQLCHAR msg[512]; SQLSMALLINT msg_len; while ((ret = SQLGetDiagRec(handle_type, handle, i, sqlstate, &native_error, msg, sizeof(msg), &msg_len)) == SQL_SUCCESS) { printf("SQLSTATE: %s, Native Error: %d, Message: %s\n", sqlstate, native_error, msg); i++; } } int main(void) { SQLHENV env = SQL_NULL_HENV; SQLHDBC dbc = SQL_NULL_HDBC; SQLRETURN ret; ret = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &env); SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); ret = SQLAllocHandle(SQL_HANDLE_DBC, env, &dbc); SQLCHAR conn_str[] = "DRIVER={ODBC Driver 17 for SQL Server};" "SERVER=localhost;" "DATABASE=TestDB;" "UID=sa;" "PWD=YourStrongPassword;" "TrustServerCertificate=yes;"; SQLCHAR out_str[1024]; SQLSMALLINT out_len; ret = SQLDriverConnect(dbc, NULL, conn_str, SQL_NTS, out_str, sizeof(out_str), &out_len, SQL_DRIVER_NOPROMPT); if (SQL_SUCCEEDED(ret)) { printf("连接成功\n"); } else { show_error(SQL_HANDLE_DBC, dbc); } if (dbc != SQL_NULL_HDBC) { SQLDisconnect(dbc); SQLFreeHandle(SQL_HANDLE_DBC, dbc); } if (env != SQL_NULL_HENV) { SQLFreeHandle(SQL_HANDLE_ENV, env); } return 0; }

SQL_DRIVER_NOPROMPT这个参数的意思是：如果连接地址不对，程序直接返回错误码而不是弹出ODBC配置对话框。这在自动化运行和后台服务里特别重要，不然半夜运行的程序突然弹个对话框等你选择，那就尴尬了。

SQLGetDiagRec用来获取错误信息。ODBC错误码是一串五位字符，最前面是SQLSTATE，后面是厂商错误码和描述信息。这个函数在调试时价值巨大，所有连接失败、执行失败，第一步就打印它。

4. 从连接到操作：完整的增删改查代码

4.1 查询数据并绑定列

连接建立后，下一步是分配语句句柄并执行SQL。对于没有输入参数的SELECT，可以直接用SQLExecDirect执行。但为了让结果能进到C变量里，要用SQLBindCol绑定列。核心逻辑如下：

SQLHSTMT stmt = SQL_NULL_HSTMT; SQLAllocHandle(SQL_HANDLE_STMT, dbc, &stmt); ret = SQLExecDirect(stmt, (SQLCHAR*)"SELECT id, username, age FROM users", SQL_NTS); if (!SQL_SUCCEEDED(ret)) { show_error(SQL_HANDLE_STMT, stmt); SQLFreeHandle(SQL_HANDLE_STMT, stmt); return 1; } SQLINTEGER id = 0, age = 0; SQLCHAR username[128]; SQLLEN id_len = 0, age_len = 0, username_len = 0; SQLBindCol(stmt, 1, SQL_C_SLONG, &id, 0, &id_len); SQLBindCol(stmt, 2, SQL_C_CHAR, username, sizeof(username), &username_len); SQLBindCol(stmt, 3, SQL_C_SLONG, &age, 0, &age_len); while (SQLFetch(stmt) == SQL_SUCCESS) { printf("id=%d, username=%s, age=%d\n", id, username, age); } SQLFreeHandle(SQL_HANDLE_STMT, stmt);

SQLBindCol的第二个参数是从1开始的列序号，第三个参数指定C数据类型。int类型对应SQL_C_SLONG，char数组对应SQL_C_CHAR。如果你把SQL_C_SLONG绑定到一个SQLINTEGER变量，基本上不会出错，因为它俩都是32位有符号整数。

还有一点容易忽略：SQLLEN类型的长度变量。SQLFetch返回后，长度变量里保存的是实际取到数据的字节数，可以用来判断字符串是否被截断。比如username列长度是128字节，而查出来的名字有150字节，长度变量就会大于缓冲区容量，说明数据被截断了，程序里可以加个判断给出提示。

如果用户名里包含中文，SQL_C_CHAR绑定就悬了，极大概率乱码。因为SQL Server传回的是GBK或UTF-8，取决于驱动程序配置，而控制台不一定按相同编码解析。最稳妥的做法是用宽字符绑定：

SQLWCHAR wusername[128]; SQLBindCol(stmt, 2, SQL_C_WCHAR, wusername, sizeof(wusername), &username_len); printf("username=%ls\n", wusername);

SQLWCHAR在Windows里就是wchar_t，16位，对应SQL Server的Unicode数据。SQL_C_WCHAR把数据库的NVARCHAR转成UTF-16放到缓冲区里，这样中文不乱码。代价是缓冲区大小翻倍，但现代机器完全不是问题。

4.2 插入、更新、删除时用参数化绑定

日常开发中，INSERT、UPDATE、DELETE往往带业务数据，如果直接拼SQL字符串，会遇到两个麻烦：一是引号转义恶心，二是SQL注入风险。拼字符串的方式在控制台程序里好像没什么大不了，但一旦程序暴露在网络里，攻击者可以把参数写成特殊值绕过校验，这问题就大了。所以这里唯一推荐的做法是SQLPrepare + SQLBindParameter + SQLExecute，也就是参数化查询。

来看插入的代码：

SQLHSTMT stmt = SQL_NULL_HSTMT; SQLAllocHandle(SQL_HANDLE_STMT, dbc, &stmt); SQLWCHAR wname[] = L"赵六"; SQLINTEGER age = 22; ret = SQLPrepare(stmt, (SQLCHAR*)"INSERT INTO users(username, age) VALUES(?, ?)", SQL_NTS); ret = SQLBindParameter(stmt, 1, SQL_PARAM_INPUT, SQL_C_WCHAR, SQL_WVARCHAR, wcslen(wname), 0, wname, 0, NULL); ret = SQLBindParameter(stmt, 2, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &age, 0, NULL); ret = SQLExecute(stmt); if (!SQL_SUCCEEDED(ret)) { show_error(SQL_HANDLE_STMT, stmt); } SQLFreeHandle(SQL_HANDLE_STMT, stmt);

SQLBindParameter参数很多，但核心需要记住的是这几个：第1个参数是占位符序号，第2个表示这是输入参数，第3个是C语言侧数据类型，第4个是SQL侧数据类型，第5个是列长度（字符串时有用），后面是数据指针。只要C类型和SQL类型对应关系正确，多数时候不用死记。

还有一个隐藏好处：参数化之后，SQL语句文本是固定的，SQL Server可以重复使用缓存的执行计划。如果循环一万次插入相同结构的数据，性能比每次拼接SQL高不少。我之前在一个采集程序里循环插入5000条记录，改成参数化后耗时降到原来的三分之一。

更新和删除操作套路完全一样，只需要把SQL语句换成对应的文，参数顺序对应好即可：

// 按id更新年龄 ret = SQLPrepare(stmt, (SQLCHAR*)"UPDATE users SET age=? WHERE id=?", SQL_NTS); SQLBindParameter(stmt, 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &age, 0, NULL); SQLINTEGER target_id = 5; SQLBindParameter(stmt, 2, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &target_id, 0, NULL); SQLExecute(stmt); // 按id删除 ret = SQLPrepare(stmt, (SQLCHAR*)"DELETE FROM users WHERE id=?", SQL_NTS); SQLBindParameter(stmt, 1, SQL_PARAM_INPUT, SQL_C_SLONG, SQL_INTEGER, 0, 0, &target_id, 0, NULL); SQLExecute(stmt);

4.3 事务控制

数据库操作不是永远一条SQL就完事。比如设备配置程序要同时更新两张表，第一张成功第二张失败，如果没有事务，数据就处于中间状态，脏数据后期排查非常痛苦。ODBC的事务控制不算复杂，关键是理解自动提交模式。

默认情况下，ODBC连接处于自动提交模式，每条SQL执行完立即提交。要开启手动事务，先把自动提交关掉：

SQLSetConnectAttr(dbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF, 0);

之后所有SQL都在同一个事务里，直到你调用SQLTransact决定提交还是回滚：

// 执行多条SQL if (all_success) { SQLTransact(env, dbc, SQL_COMMIT); } else { SQLTransact(env, dbc, SQL_ROLLBACK); } // 恢复自动提交 SQLSetConnectAttr(dbc, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_ON, 0);

all_success只是一个示意变量，实际代码里需要在每步SQL执行后检查返回值，一旦失败就跳转或设置标志位。有一点要提醒：如果程序在事务未提交时异常退出，连接断开，SQL Server会自动回滚未提交的事务，所以不必担心崩溃导致半个事务落库。

还有个细节：ODBC手册里建议在SQLTransact之前先释放语句句柄，否则部分驱动会报错。我自己测试时发现SQL Server驱动并没有强制，但稳妥起见还是先释放本事务内使用过的语句句柄，再提交事务。

5. 实操中遇到的坑与排查实录

5.1 连接失败：先把这几个原因过一遍

连接报错是所有新手遇到的第一个坎。通常SQLSTATE=08001表示不能建立连接，检查顺序应该是这样：

SQL Server服务是否在运行：Windows服务管理器里看MSSQLSERVER状态，大部分情况就是服务没启动。
防火墙是否放行1433端口：SQL Server默认端口是1433，但如果你改了端口，连接字符串的SERVER里要写成“IP,端口”格式，比如“192.168.1.100,14333”。局域网环境最容易忽略的就是Windows防火墙，连接MySQL、连接SQL Server都栽在这。
驱动位数是否匹配：这是典型的32/64位陷阱。如果你的程序编译成x86，却只装了64位ODBC驱动，连接字符串里指定了驱动名，但找不到，报错通常是IM002或IM014。反过来也一样。解决方法是按程序位数安装对应位数的驱动，或把程序改成Any CPU架构而不是指定x86。
登录账号权限：如果SQLSTATE=28000，那就是用户名、密码或登录类型问题。检查SQL Server是否允许SQL登录，检查账号是否被禁用或锁定。
服务器证书问题：ODBC 18默认加密，报08001或SSL握手错误时，先加TrustServerCertificate=yes试一下。

最烦人的是服务器名写错。当局域网里SQL Server用命名实例时，写主机名不写实例名连不上，写“主机名\实例名”又要注意反斜杠在C字符串里要转义。比如：

"SERVER=192.168.1.100\\SQLEXPRESS;"

反斜杠在C语言里是转义符，所以“\”才是真正的一个反斜杠。这个错误排查起来特别隐蔽，代码里看着字符串没毛病，实际上因为少了转义，驱动把“\S”当成特殊字符处理，连接必然失败。

5.2 中文乱码：从根源上解决

中文乱码的本质是字符编码不一致。C语言里如果用SQL_C_CHAR绑定和printf输出，控制台、数据库排序规则、驱动转换三层叠加，很容易各说各话。我建议的解决路径是：

表和字段都用NVARCHAR/NCHAR类型，也就是SQL Server的Unicode类型。
C语言侧用SQLWCHAR数组和SQL_C_WCHAR绑定。
输出时用“%ls”而不是“%s”，这是宽字符输出格式。
源文件保存为带BOM的UTF-8，或者在工程属性里把字符集改成“使用Unicode字符集”。

还有一个容易被忽略的点：SQL字符串字面量的N前缀。如果你用SQLExecDirect直接执行带中文字面量的SQL，建议写成：

SQLExecDirect(stmt, (SQLCHAR*)"SELECT * FROM users WHERE username=N'张三'", SQL_NTS);

N前缀告诉SQL Server这个字符串是Unicode。如果不加，从ODBC驱动传给SQL Server的字节会被按数据库默认代码页解释，很可能查不到结果。

5.3 密码过期与SQL Server登录策略

开发测试时最烦人的是SQL Server账号密码过期。有些机器装的是SQL Server 2012及以上版本，开启了密码过期策略，你连接字符串里写死的密码过几天突然就失效，程序报28000。这个问题在开发环境有三个处理方式：

用SSMS登录进去执行ALTER LOGIN sa WITH PASSWORD = '新密码';，然后更新程序里的连接字符串。
修改账号属性，把“强制密码过期”关掉，再将检查策略改成OFF：
```
ALTER LOGIN sa WITH CHECK_EXPIRATION = OFF; ALTER LOGIN sa WITH CHECK_POLICY = OFF;
```
换用Windows身份验证，连接字符串里写Trusted_Connection=yes，不依赖数据库账号密码。

需要说明一下，关闭密码策略只能在开发和测试环境做，生产系统为了过安全审计，密码策略必须开着。这个区别要分清楚，否则运维同事会来找你麻烦。

5.4 日志：让问题不靠猜

程序连不上数据库，最怕的就是“咦，刚才还能连”。给程序加一个简单的日志输出，比任何调试器都好使。写日志不复杂，把show_error函数的输出加上时间戳和来源方位写到一个文件里就行：

void log_error(const char* tag, SQLSMALLINT handle_type, SQLHANDLE handle) { FILE* fp = fopen("db_error.log", "a"); fprintf(fp, "[%s] ", tag); // SQLGetDiagRec输出内容 fprintf(fp, "\n"); fclose(fp); show_error(handle_type, handle); // 同时终端可见 }

实测下来，加了日志之后排查效率大幅提升，因为现场返回的SQLSTATE和Native Error都是确定性线索，搜一下就知道问题出在驱动层还是SQL层。没有日志的时候，凭记忆复盘连接失败原因，基本是浪费时间。

6. 性能与安全方面的几点心得

6.1 参数绑定真的能防SQL注入吗

经常有人问这个问题。答案是：参数绑定能够杜绝SQL注入，前提是你把参数绑定当作唯一的传值方式，并且不在SQL文本里拼接用户输入。原理很简单：SQLPrepare编译的语句里，占位符的位置被当成数据，不管传进来什么值，驱动都会把它转义或者按二进制参数送到服务端解析，永远不会被当成SQL代码执行。

对比一下拼接方式的典型死法：

// 危险写法 char sql[512]; sprintf(sql, "SELECT * FROM users WHERE username='%s'", input); SQLExecDirect(stmt, (SQLCHAR*)sql, SQL_NTS);

如果input是“' OR '1'='1”，拼出来就是“SELECT * FROM users WHERE username='' OR '1'='1'”，整个表就查出来了。参数绑定没有这个问题，因为占位符接收的是数据流，不是文本展开。

C语言里没有框架帮你强制参数化，靠的是自我约束。我给自己定的规矩是：凡是外部输入的数据，一律走SQLBindParameter；只有常量SQL片段才用SQLExecDirect直接执行。

6.2 大批量数据操作时的性能建议

程序里循环一万次SQLExecute，发现速度很慢，先不要怪数据库，先看代码。两个常见的优化点：

用参数化查询复用执行计划，已经说过了。这是成本最低的优化。
多条INSERT用单个事务包起来，提交频率从一万次降到一次，性能提升非常明显。注意别把整个循环塞进一个大事务，如果中途有一两条坏数据，回滚会把前面几千条也撤了。稳妥的做法是每500条或1000条一个事务块。
如果数据量到了几十万级别，建议改用批量复制接口。SQL Server有专门的bcp协议和API，通过ODBC也能调用SQLBulkOperations。但这个接口需要设计列映射，代码复杂度更高，没必要为了几千条数据去折腾。

6.3 连接字符串里的凭据别硬编码

我的习惯是把数据库连接参数抽到配置文件里，至少是读取环境变量。原因很现实：程序发给客户或运维时，他们不可能因为数据库密码改了来改源码重新编译。连接字符串放到ini或json文件里，运维可以自己改，程序重启即可生效。如果担心配置文件泄露，可以用Windows的DPAPI做加密，把加密后的内容放配置文件里，程序启动时解密。

密码加不加密是安全投入与便利性的权衡。如果是内网工具，加密需求不高；如果是暴露到外网的服务，连接字符串还硬编码的话，相当于把钥匙放在门垫下面。我的原则是：程序里居然写密码，那就至少要写注释说明这是测试环境专用，并且有计划的替换机制。

6.4 使用连接池，而不是频繁创建断开连接

ODBC本身支持连接池。可以在程序初始化时通过SQLSetEnvAttr设置连接池属性：

SQLSetEnvAttr(env, SQL_ATTR_CONNECTION_POOLING, (SQLPOINTER)SQL_CP_ONE_PER_DRIVER, 0);

SQL_CP_ONE_PER_DRIVER是最常用的模式，表示每个驱动维护一个连接池。启用之后，关闭连接不会真的断开，而是归还到池里，下一次连接复用这个物理连接。对于那种每次操作数据库都要新开连接的程序，连接池能省下TCP握手、TLS握手和登录校验的开销，效果明显。

但连接池也不是银弹。如果你每次都设置自定义连接属性，比如修改当前数据库、设置会话选项，连接池可能把状态复用到下个用户，造成逻辑错误。SQL Server驱动文档里对这类属性有严格说明，要么用连接字符串指定，要么在每次使用前显式设置回来。

结尾：我的实际体会

折腾完这一套，我最大的感受是：C语言操作SQL Server不是什么高不可攀的黑科技，它更像一套固定流程——环境句柄、连接句柄、语句句柄，然后记住“所有业务数据都走参数绑定”这一条铁律。整个过程中，真正耗时间的还是环境配置和编码细节，比如32/64位驱动匹配、TLS证书参数、宽字符绑定，这些坑没有文档会一次性写给你，只能一个个踩。最后再分享一个小技巧：调试阶段把ODBC错误输出函数写好，遇到问题第一时间打印SQLSTATE，大部分连接问题都能在五分钟内定位到根因。这个思路如果做对了，后面的开发就很顺了。

资讯详情

C语言连接SQL Server实战：ODBC接口完整教程