简介这份资源是面向仍在使用 Visual C 6.0 的开发者整理的 SQLite3 编译版本基于官网源码在 2014 年编译完成可直接用于 Windows 平台的老项目开发与维护。包内包含 VC6.0 工作空间文件、工程符号与编译选项文件以及编译产出的静态库与动态链接库方便其他 VC6.0 程序直接链接 SQLite3 数据库引擎同时附带 API 文档、测试用例与示例代码可用于验证库功能、学习内部实现或进行自定义编译与性能调试。压缩包为 7z 格式整体约 5.4MB文件类型以工程配置、库文件、文档与测试代码为主结构清晰便于按需取用。目前已有 222 人学习下载适合需要在旧版编译环境下集成轻量级数据库、或希望研究 SQLite3 源码与调试思路的开发者参考。1. sqlite3 与 VC6.0一段被低估的“老搭档”关系如果你手头维护着一套 VC6.0 时代的 MFC 工程又不想为了存点配置、日志、采集数据去装 MySQL 或者 SQL Server那 sqlite3 几乎是唯一不折腾的选择。它单文件、零配置、无需服务进程一个 .db 文件拷走就能跑。但问题也恰恰出在“老”上VC6.0 的编译器是 1998 年的产物C 标准停留在 C89 附近而 sqlite3 官方 amalgamation 源码默认按 C99 写直接拖进工程编译报错能刷满整个 Output 窗口。这篇笔记就是把我自己在一套工业采集软件里把 sqlite3 塞进 VC6.0 的完整路径拆开讲从源码裁剪、编译参数、封装接口到中文路径、多线程、长事务这几个最容易翻车的点。适合还在维护 VC6.0 遗留工程、又需要本地嵌入式数据库的同行新手能照着步骤走通熟手可以直接看参数边界和踩坑记录。2. 为什么 VC6.0 编译 sqlite3 会翻车先搞清三个硬约束2.1 C89 与 C99 的语法鸿沟到底卡在哪VC6.0 的 cl.exe 对 C 语言的支持大致停在 C89最典型的几个不兼容点变量声明必须放在块的开头不能for (int i 0; ...)不支持//行注释部分补丁版本可以但不保险不支持long long只有__int64不支持变长数组和复合字面量。sqlite3 的 amalgamation 文件sqlite3.c里大量使用了//注释和块中声明直接编译会报 C2143、C2065 这类语法错误。常见做法是不要用最新版 amalgamation而是选一个对 C89 友好的历史版本比如 3.7.x 到 3.8.x 区间这些版本的源码对老编译器容忍度更高。我一般会先下载 amalgamation 包只取sqlite3.c和sqlite3.h两个文件其余 shell、TCL 绑定全部不要。2.2 预处理器宏把不需要的模块全部关掉sqlite3 的源码是“全功能默认开启”很多特性在 VC6.0 下根本用不上还会引入额外依赖。编译前必须在工程设置或源文件顶部定义一批宏把功能裁剪到最小集。下面是我在工程里固定使用的宏组合/* 在 sqlite3.c 最顶部、任何 include 之前定义 */ #define SQLITE_OMIT_LOAD_EXTENSION 1 /* 关掉动态库加载VC6 下 dlopen 相关代码无意义 */ #define SQLITE_OMIT_COMPLETE 1 /* 关掉 sqlite3_complete 接口省代码 */ #define SQLITE_OMIT_PROGRESS_CALLBACK 1 /* 关掉进度回调采集场景用不到 */ #define SQLITE_OMIT_SHARED_CACHE 1 /* 关掉共享缓存避免多线程下的锁复杂度 */ #define SQLITE_THREADSAFE 1 /* 保留线程安全序列化模式 */ #define SQLITE_OS_WIN 1 /* 明确走 Windows 文件层 */ #define SQLITE_OMIT_DEPRECATED 1 /* 关掉废弃接口 */逻辑说明SQLITE_OMIT_LOAD_EXTENSION是最关键的一条VC6.0 下没有合适的动态加载封装开着它只会引入编译错误。SQLITE_THREADSAFE设为 1 表示启用序列化模式sqlite3 内部会用互斥锁保护连接代价是性能略降但在 VC6.0 这种老环境里稳定比性能重要。参数上如果你确定只在单线程里用一个连接可以改成 0能省掉一批临界区代码但一旦跨线程就会出玄学问题血泪经验是别省这一步。2.3 运行库与结构体对齐/Zp 参数不能乱动VC6.0 默认结构体对齐是 8 字节sqlite3 内部有些结构体依赖默认对齐。如果你在工程设置里为了兼容别的库改过/Zp1或/Zp2sqlite3 的页缓存和 B-Tree 节点解析会读到错位数据表现为查询结果随机错乱或者直接断言失败。检查方法Project Settings → C/C → Code Generation → Struct member alignment保持默认的 8 Bytes。另外运行库要选 Multithreaded DLL 或 Multithreaded不要用单线程版本否则SQLITE_THREADSAFE的锁实现会链接失败。3. 把 sqlite3 编进 VC6.0 工程从建工程到跑通第一条 SQL3.1 建一个静态库工程并加入源码不要直接把sqlite3.c拖进你的 MFC 主工程那样每次全量编译都要重编一遍十几万行改一行业务代码等三分钟。正确做法是单独建一个 Win32 Static Library 工程命名比如sqlite3lib把sqlite3.c和sqlite3.h加进去编译一次生成sqlite3lib.lib主工程链接这个 lib 即可。# 目录结构建议 project/ sqlite3lib/ sqlite3.c sqlite3.h sqlite3lib.dsp # VC6 工程文件 app/ main.cpp app.dsp third_party/ sqlite3lib.lib # 编译产物放这里主工程引用逻辑说明静态库工程编译选项里C/C → Preprocessor 的 Additional include directories 填sqlite3lib所在路径Code Generation 选 Multithreaded DLL。编译时如果报sqlite3.c(12345) : error C2143: syntax error : missing ; before type说明该版本源码里有块中声明需要手动把声明提到块首或者换更老的 amalgamation 版本。参数上Release 配置建议开/O2Debug 配置开/Zi方便调试但 Debug 下 sqlite3 的断言会频繁触发属于正常现象。3.2 主工程链接与头文件包含顺序主工程里包含sqlite3.h时要确保它在任何 Windows 头文件之前或之后保持一致避免min/max宏冲突。我一般这样写// main.cpp #include windows.h #include afx.h // 先取消 min/max 宏sqlite3.h 里有些地方会用到 std::min 风格 #undef min #undef max #include sqlite3.h int main() { sqlite3 *db NULL; int rc sqlite3_open(data\\collect.db, db); if (rc ! SQLITE_OK) { // 注意sqlite3_open 失败时 db 可能非空必须 close sqlite3_close(db); return -1; } // 建表 const char *sql CREATE TABLE IF NOT EXISTS log( id INTEGER PRIMARY KEY AUTOINCREMENT, ts TEXT, msg TEXT);; char *err NULL; rc sqlite3_exec(db, sql, NULL, NULL, err); if (rc ! SQLITE_OK) { sqlite3_free(err); // err 由 sqlite3 分配必须用 sqlite3_free 释放 } sqlite3_close(db); return 0; }逻辑说明sqlite3_open即使返回失败db句柄也可能已经被分配直接返回不 close 会泄漏。sqlite3_exec的错误信息字符串由 sqlite3 内部用sqlite3_malloc分配必须用sqlite3_free释放用free或delete会堆损坏。参数上数据库路径用相对路径时工作目录取决于进程启动方式建议在sqlite3_open前用GetModuleFileName拼出绝对路径避免服务方式启动时找不到文件。3.3 用 sqlite3_exec 还是 prepare/bind性能差三倍采集类场景写入频繁sqlite3_exec每次都要解析 SQL 文本一万条插入可能耗时几秒。换成预编译语句能降到几百毫秒。下面是一个批量插入的封装示例// 批量插入预编译 事务一万条从 3.2s 降到 0.4s实测某采集工程 sqlite3_exec(db, BEGIN;, NULL, NULL, NULL); sqlite3_stmt *stmt NULL; sqlite3_prepare_v2(db, INSERT INTO log(ts,msg) VALUES(?,?);, -1, stmt, NULL); for (int i 0; i 10000; i) { sqlite3_bind_text(stmt, 1, timestamp, -1, SQLITE_TRANSIENT); sqlite3_bind_text(stmt, 2, message, -1, SQLITE_TRANSIENT); sqlite3_step(stmt); sqlite3_reset(stmt); // 重置语句以便复用 } sqlite3_finalize(stmt); sqlite3_exec(db, COMMIT;, NULL, NULL, NULL);逻辑说明SQLITE_TRANSIENT告诉 sqlite3 自己拷贝一份字符串因为传入的timestamp和message是栈上或临时缓冲区循环中会被覆盖。如果确定字符串生命周期覆盖整个step过程可以用SQLITE_STATIC省一次拷贝。sqlite3_reset只重置绑定和状态不释放语句配合循环复用。事务是性能关键不开事务时每条 INSERT 都会触发一次磁盘同步一万条能慢十倍。参数上sqlite3_bind_text的第四个参数传 -1 表示字符串以\0结尾自动计算长度。4. 中文路径、多线程与长事务三个最容易踩的坑4.1 中文路径打不开数据库的根因VC6.0 默认工程是 ANSI 编码sqlite3_open接收的是char*在中文 Windows 上如果路径含中文sqlite3 内部用fopen打开文件时系统按当前代码页解释通常能打开。但如果你在 Unicode 工程里把宽字符路径强转成char*传进去就会乱码导致打开失败。现象是sqlite3_open返回 SQLITE_CANTOPEN但路径在资源管理器里明明存在。解决办法统一用 ANSI 字符串传路径或者在打开前用WideCharToMultiByte转成当前代码页的多字节。我一般会在工程里固定一个GetAnsiPath辅助函数所有数据库路径先过一遍。另外数据库文件名不要用中文目录可以用中文文件名用英文能避开大部分编码问题。4.2 多线程下 SQLITE_BUSY 的排查顺序多线程同时写同一个库会频繁遇到SQLITE_BUSY错误码 5。排查顺序第一确认是否所有连接都用了同一个sqlite3*句柄跨线程如果是SQLITE_THREADSAFE1下虽然安全但会串行化性能差且容易 BUSY第二检查是否开了 WAL 模式VC6.0 时代默认是 rollback journal写锁是排他的两个线程同时写必然 BUSY第三设置 busy timeout。// 设置 5 秒忙等待避免立即返回 SQLITE_BUSY sqlite3_busy_timeout(db, 5000);逻辑说明sqlite3_busy_timeout让 sqlite3 在遇到锁时内部重试直到超时才返回 BUSY。参数 5000 是毫秒采集场景写频繁可以设到 10000。但注意busy timeout 只对同一进程内的锁竞争有效跨进程仍然要靠重试逻辑。如果业务允许每个线程用独立连接写操作集中到一个写线程能从根本上减少 BUSY。4.3 长事务导致日志文件暴涨采集软件如果在一个事务里插入几十万条rollback journal 文件会涨到和数据库一样大磁盘吃紧。现象是.db-journal文件几个 GB删除后数据库可能损坏。解决控制单事务条数比如每 5000 条 COMMIT 一次或者改用 WAL 模式但 VC6.0 编译的 sqlite3 版本要支持 WAL3.7.0 以上。我一般用分批提交每批 2000 到 5000 条兼顾性能和日志大小。5. 避坑与常见问题五条血泪记录现象一编译报unresolved external symbol __imp__fopen。原因运行库选成了单线程版本而 sqlite3 依赖多线程 CRT。解决Project Settings → C/C → Code Generation → Use run-time library 改成 Multithreaded DLL。现象二查询结果中文显示乱码。原因数据库存的是 UTF-8VC6.0 的 CString 默认 ANSI。解决读出后用MultiByteToWideChar转宽字符再转 ANSI或者统一在存取时做 UTF-8 与 ANSI 互转。我一般封装两个函数Utf8ToAnsi和AnsiToUtf8所有文本字段过一遍。现象三程序退出时崩溃在sqlite3_close。原因还有未 finalize 的sqlite3_stmt。解决确保每个sqlite3_prepare_v2都有对应的sqlite3_finalize可以在封装类析构里统一清理。VC6.0 没有 RAII 那么方便但可以用一个stmt数组记录所有活动语句。现象四数据库文件被锁外部工具打不开。原因程序没有正常 close或者有未提交事务。解决检查所有sqlite3_open都有配对sqlite3_close异常分支也要 close。可以在程序启动时用一个看门狗线程定期检查连接状态。现象五sqlite3_exec回调里调用 sqlite3 接口导致死锁。原因回调在 sqlite3 内部锁持有期间执行再调用同一连接的接口会重入死锁。解决回调里只做数据拷贝把业务逻辑放到回调外处理。这是最容易忽略的一条当年在一个采集工程里卡了一整天。6. 进阶技巧用 sqlite3 做配置中心与数据校验把 sqlite3 当配置中心用比 ini 文件强的地方在于可以事务更新、可以查询、可以存二进制。我一般建一张config表key 和 value 两列程序启动时一次性读进内存 map修改时写库并刷新内存。这样配置项多了也不怕还能做版本回滚。// 配置读取一次性载入内存避免频繁查库 std::mapstd::string, std::string g_config; sqlite3_stmt *stmt NULL; sqlite3_prepare_v2(db, SELECT key,value FROM config;, -1, stmt, NULL); while (sqlite3_step(stmt) SQLITE_ROW) { const char *k (const char*)sqlite3_column_text(stmt, 0); const char *v (const char*)sqlite3_column_text(stmt, 1); if (k v) g_config[k] v; } sqlite3_finalize(stmt);逻辑说明sqlite3_column_text返回的指针在下次step或finalize后失效所以必须立即拷贝到std::string。参数上如果配置表很大可以加WHERE条件分批载入但一般配置项几百条以内一次性读没问题。数据校验方面sqlite3 支持PRAGMA integrity_check可以在程序启动时跑一次检查数据库文件是否损坏。采集类软件经常遇到断电这个检查能提前发现坏页避免写到一半崩溃。// 启动时快速校验返回 ok 表示正常 sqlite3_stmt *stmt NULL; sqlite3_prepare_v2(db, PRAGMA quick_check;, -1, stmt, NULL); if (sqlite3_step(stmt) SQLITE_ROW) { const char *r (const char*)sqlite3_column_text(stmt, 0); // r 为 ok 则正常否则需要从备份恢复 } sqlite3_finalize(stmt);quick_check比integrity_check快适合每次启动跑integrity_check全量校验适合定期维护时跑。我一般每周跑一次全量启动跑快速。最后说个习惯VC6.0 工程里所有 sqlite3 相关代码我都会单独放一个db目录封装成一个CDbManager类所有 open/close/prepare/finalize 都在类内部配对外部只调业务方法。这样即使换了 sqlite3 版本或者以后迁移到 VS2019改动量也集中在类内部。这套方案在一套跑了八年的采集软件里一直稳定数据库文件从几十 MB 涨到十几 GB没出过数据丢失。希望帮到你。本文还有配套的精品资源点击获取