简介面向仍在使用 Visual C 6.0 维护 Windows 老项目的开发者这套 SQLite3 源码与编译产物可省去自行移植、反复试错编译的麻烦。压缩包为 7z 格式体积约 5.4MB内含 VC6.0 工作空间与工程配置、编译得到的静态库与动态库以及用于验证功能的测试示例和对应版本参考文档工程配置齐全打开后即可复现构建过程也便于对照源码理解 SQLite3 的接口设计与内部实现属于偏进阶的底层数据库学习材料。已有 228 人学习下载多为需要兼容旧编译环境的团队。借助其中的库文件与示例代码读者可较快把这款轻量级关系型数据库接入既有工程完成数据存储与检索模块的搭建也可通过测试用例核对链接方式与运行表现排查静态库、动态库调用中的常见问题或在此基础上裁剪编译选项、做定制化改造。1. VC6 里塞进 SQLite3先把版本代差算清楚把 sqlite3 往 vc6.0 里装失败的概率比大多数人预估的高。某开发者接手一个 2003 年留下的 MFC 老工程想加个本地库存运行配置第一反应是把新下载的 amalgamation 包里的 sqlite3.c 直接拖进工程Build 一按输出窗口满屏 C2059、C2065编译器那个黑匣子里全是它不认识的语法。VC6 的编译器停在 C89 那一代SQLite 较新的分支早就默认 C99 起步中间隔着一整代工具的差距这不是改两个宏就能糊过去的。这类环境在工控上位机、老医疗设备、还有一堆没预算重写的桌面程序里依然常见装不好的表现要么是编不过要么是编过了运行期 sqlite3_open 返回 SQLITE_CANTOPEN。下面按我实际走通的顺序从挑版本、摆目录、编静态库到验证跑通一步步写。2. 挑版本和摆目录amalgamation 包在 VC6 下的取舍2.1 为什么不能直接上最新 amalgamationSQLite 官方给的那个 sqlite3.c 单文件包是把上百个源文件拼成一个翻译单元方便嵌入。这个设计对现代编译器很友好对 VC6 却是灾难文件体积大单个 .c 动辄五六兆VC6 的编译器前端在处理这种规模时会先把内存吃满语法层面又大量使用 C99 特性stdint.h、long long、块中间声明变量、变参宏VC6 一个都不认。我这边的判断标准很简单优先选 3.7.x 到 3.8.x 之间的 amalgamation 分支。这个区间的源码还保留着对老编译器的兼容分支sqlite3.h里对 MSVC 的_MSC_VER判断也覆盖到 1200 这一档——VC6 的_MSC_VER正好是 1200刚好卡在分支边界上属于能用但要看运气的位置。再往上的 3.3x 系列源码里已经默认stdint.h存在int64_t、uint32_t直接用VC6 编到一半就报fatal error C1083: Cannot open include file: stdint.h。如果你手上的业务代码已经依赖新版本的某个特性比如窗口函数或者 JSON1 扩展那我的建议是别在 VC6 里硬啃把 SQLite 的访问层抽成一个独立的 DLL用新编译器编VC6 侧只保留 C 接口调用。硬要把新源码塞进 VC6改到能编过的时间成本通常超过重写访问层。提示版本不是越新越好也不是越老越稳。3.6 之前的版本在 Windows 下的文件锁实现有已知缺陷多进程访问同一个库文件时容易出现锁不释放业务上一般避开。2.2 解压之后文件怎么摆amalgamation 包解开后是一堆文件实际要用的只有三个其余可以全部丢掉。我在 D 盘建一个固定目录所有老工程共用同一份源码和库避免每个工程各编一遍。D:\sdk\sqlite3\ ├── include\ │ ├── sqlite3.h # 唯一需要被业务工程 include 的头文件 │ └── sqlite3ext.h # 只写扩展模块才用普通业务不需要 ├── src\ │ └── sqlite3.c # 唯一的编译单元 ├── lib\ │ ├── sqlite3.lib # Release 静态库 │ └── sqlite3d.lib # Debug 静态库 └── build\ # VC6 工程文件与中间产物文件职责上要分清三件事。sqlite3.c是完整的实现编译它才产生符号sqlite3.h是接口声明业务工程 include 它sqlite3ext.h是给可加载扩展用的VC6 下通常直接关掉扩展加载能力这个头文件根本不会出现。包里如果带shell.c那是命令行工具的入口里面用了不少新语法VC6 编不过删掉不影响任何东西。一个容易忽略的点sqlite3.c里已经#include sqlite3.h所以编译时头文件搜索路径必须能找到同目录或指定目录下的sqlite3.h。最省事的做法是把sqlite3.h复制一份到src\下与.c同目录这样编译期和业务期用的是同一份头文件避免版本错位导致的结构体布局不一致。2.3 编译前必须定的几个预处理宏VC6 的工程设置里预处理宏是在 Project → Settings → C/C → Preprocessor → Preprocessor definitions 里填的。这几个宏决定了编出来的库长什么样改动之后必须整库重编不能只重编业务代码。宏建议值作用与取舍SQLITE_THREADSAFE11 为序列化模式多线程共用一个句柄也安全代价是每次调用加锁0 关闭全部互斥速度最快但只能单线程用2是多线程模式句柄不能跨线程共享SQLITE_OMIT_LOAD_EXTENSION定义关掉load_extensionVC6 下加载 DLL 的扩展路径基本用不上关掉能省一批符号SQLITE_OMIT_DEPRECATED定义去掉sqlite3_...那批废弃接口减小体积SQLITE_ENABLE_COLUMN_METADATA按需需要拿到结果列的原表名、库名时才开开了库会大一圈SQLITE_OS_WIN定义显式指定 Windows 后端VC6 下自动探测有时会走偏SQLITE_INT64_TYPE__int64版本里带这个入口时定义它直接绕开int64_t的类型定义问题SQLITE_THREADSAFE是最需要想清楚的一个。老上位机程序经常是 UI 线程写库、采集线程读库那就老老实实设成 1性能损失在毫秒级换来的是不用自己管句柄生命周期。如果整个程序只有一根线程碰数据库设成 0 能省下可观的开销但之后任何人加一根线程都会变成随机崩溃这种坑事后极难定位。3. 编静态库VC6 工程怎么建、选项怎么点3.1 新建 Win32 Static Library 工程不要图省事把sqlite3.c直接加进业务工程里一起编。业务工程每次改一行代码就要重编这个五兆的文件一次完整构建能拖到几分钟改到第十次就想砸键盘。单独建一个静态库工程编一次之后业务工程只链接.lib。操作路径是 File → New → Projects → Win32 Static Library工程名填sqlite3位置选D:\sdk\sqlite3\build。向导第二步会问要不要预编译头和 MFC 支持两个都不勾。建完之后在 FileView 里把sqlite3.c添加进 Source Filessqlite3.h添加进 Header Files。接着配两个 Build 配置。VC6 默认只有 Win32 Debug 和 Win32 ReleaseDebug 配置的输出文件名改成sqlite3d.libRelease 保持sqlite3.lib。业务工程在 Debug 下链接带 d 的那个Release 下链接不带 d 的两边必须严格对应。混用是后面链接错误的高发区我在第 5 章会细说。3.2 必须关掉的预编译头和必须打开的编译选项静态库工程默认会尝试使用预编译头而sqlite3.c里没有#include stdafx.h编译会直接报fatal error C1010: unexpected end of file while looking for precompiled header directive。在 Project → Settings → C/C → Precompiled Headers 里选 “Not using precompiled headers”两个配置都要改。其余选项在 C/C 面板里逐项确认# 等价于 VC6 工程设置里勾选的选项用命令行写出来更清楚 cl /nologo /c /W3 /O2 /MT /Zm1500 ^ /DSQLITE_THREADSAFE1 ^ /DSQLITE_OMIT_LOAD_EXTENSION ^ /DSQLITE_OMIT_DEPRECATED ^ /DSQLITE_OS_WIN ^ /FoRelease\sqlite3.obj ..\src\sqlite3.c lib /nologo /OUT:Release\sqlite3.lib Release\sqlite3.obj/c表示只编译不链接静态库工程本来就不做链接阶段。/W3是警告级别不建议开到/W4SQLite 内部有大量刻意为之的类型转换开高了满屏噪音反而盖住真正的错误。/O2是 Release 的优化级别Debug 配置换成/Od /Zi。/MT是静态链接 C 运行时这条最容易被忽略如果你的业务工程用的是/MD动态链接 CRT库和主程序会各自持有一份堆管理器和文件句柄表sqlite3_malloc分配的内存由主程序的free释放时行为未定义症状是偶发崩溃且崩溃点跟数据库逻辑毫无关系。/Zm1500是把编译器的内存分配上限提高到默认值的 1.5 倍。VC6 编译sqlite3.c这种体量的文件时默认上限经常不够报的是fatal error C1060: compiler is out of heap space机器内存再大也没用它卡的是编译器自己申请的那块堆。这个数值从 1000 起步往上试能编过就行开太大是浪费。/Fo指定目标文件输出路径lib命令在VC98\Bin目录下如果不在 PATH 里就用完整路径调用。3.3 编完之后核对该有的符号编出.lib不等于编对了还要确认里面真的有那几个核心符号。VC6 自带的dumpbin可以做这件事# 列出静态库里的全局符号过滤出核心接口 dumpbin /symbols Release\sqlite3.lib | findstr sqlite3_open sqlite3_exec sqlite3_prepare # 只看库里有哪些目标文件正常情况下应该只有一个 sqlite3.obj lib /list Release\sqlite3.lib第一条命令的输出里每个符号前面会带External和段号看到_sqlite3_open、_sqlite3_exec、_sqlite3_prepare_v2这几个就说明导出正常。如果全是UNDEF或者压根没输出通常意味着/c没生效或者源文件根本没被加入工程。第二条命令确认库里只有一个 obj有多个说明你误把别的源文件也加进了工程。Debug 配置编出来的sqlite3d.lib体积会明显大于 Release这是调试信息造成的正常现象不用管。但两边都要各编一次并各自核对别只验证 Release 就以为 Debug 也没问题。4. 让业务工程用上它包含路径、链接与字符集4.1 三个路径要写在哪业务工程需要知道三样东西的位置sqlite3.h在哪、sqlite3.lib在哪、编库时用了哪些宏。前两个在 Project → Settings 里配第三个经常被彻底忘掉。头文件路径C/C → Preprocessor → Additional include directories填D:\sdk\sqlite3\include库路径Link → Input → Additional library path填D:\sdk\sqlite3\lib库文件名Link → General → Object/library modules追加sqlite3.lib宏定义这一项业务工程侧不需要重复定义SQLITE_THREADSAFE这些。它们影响的是库内部的实现业务代码只消费sqlite3.h里的声明。但有一种情况必须同步如果你在编库时定义了SQLITE_ENABLE_COLUMN_METADATA业务代码里用到了sqlite3_column_table_name这类接口那头文件里也要有同样的宏否则声明不出现编译报未定义。我一般的做法是业务工程里也把这一组宏原样抄一份多写一行换来的是不用记哪些是“实现宏”、哪些是“接口宏”。4.2 链接的两个写法选一个就好写法一是在 Link 设置里手工加库名缺点是换个工程就要重配一遍容易漏。写法二是在代码里用#pragma comment把链接指令写进源码/* sqlite_link.h —— 业务工程统一引这个头别各处零散 include */ #ifndef SQLITE_LINK_H #define SQLITE_LINK_H /* VC6 的预处理器支持 #pragma comment链接时自动带上对应的库 */ #ifdef _DEBUG #pragma comment(lib, sqlite3d.lib) #else #pragma comment(lib, sqlite3.lib) #endif #include sqlite3.h #endif#pragma comment(lib, ...)是 MSVC 特有的指令VC6 完全支持。_DEBUG这个宏由 IDE 在 Debug 配置下自动定义所以 Debug 和 Release 会自动选到不同的库省掉手工切换的麻烦。前提是库搜索路径已经加进 Link 的 Additional library path否则会报LINK : fatal error LNK1104: cannot open file sqlite3d.lib。这种写法还有个隐性好处把链接依赖和头文件包含绑在一起新人拿到工程不会出现“头文件找到了但库里没链接”的半吊子状态。4.3 中文路径一次从 ANSI 到 UTF-16 的转换这是 VC6 用 SQLite 最容易踩且最难查的一条。sqlite3_open接收的是 UTF-8 编码的文件名而 VC6 默认按 ANSI简体中文环境下是 GBK 代码页编译字符串字面量。程序里写sqlite3_open(D:\\数据\\demo.db, db)传进去的是 GBK 字节流SQLite 按 UTF-8 解析路径直接变成乱码返回值是SQLITE_CANTOPEN而错误信息里显示的路径看着“差不多对”特别迷惑。最省事的解法是改用宽字符接口sqlite3_open16#include windows.h #include sqlite3.h /* 封装一层业务侧只传宽字符路径避免每次手工转码 */ sqlite3* open_db_utf16(const wchar_t *wpath) { sqlite3 *db NULL; /* sqlite3_open16 接收 UTF-16 字符串VC6 支持 L 宽字符字面量 */ int rc sqlite3_open16(wpath, db); if (rc ! SQLITE_OK) { /* 打开失败时 db 可能非空必须关掉否则每次重试漏一个句柄 */ if (db) { sqlite3_close(db); db NULL; } return NULL; } /* 顺手把忙等待超时设上默认 0 意味着一撞锁立刻返回 SQLITE_BUSY */ sqlite3_busy_timeout(db, 3000); return db; }sqlite3_open16的第二个参数是sqlite3**输出第一参数是const void*实际传宽字符串指针。sqlite3_busy_timeout设成 3000 毫秒意思是遇到写锁被占用时最多等三秒再返回错误默认值是 0多线程或多进程环境下会频繁拿到SQLITE_BUSY很多“偶发写入失败”的报障都是这个默认值引起的。要注意这个封装只解决了文件名的编码问题。SQL 语句本身的文本sqlite3_exec和sqlite3_prepare仍然按 UTF-8 解释。如果 SQL 里要写中文常量比如INSERT INTO t VALUES(测试)得先把这段 SQL 从 GBK 转成 UTF-8用MultiByteToWideChar转 UTF-16 再WideCharToMultiByte转 UTF-8 两步走不能直接一步从 936 转到 65001那条路径在部分系统上会丢字符。老工程的通行做法是把所有中文常量改成绑定参数sqlite3_bind_text前统一转码逻辑更干净。5. 避坑记录VC6 编 SQLite3 的五个翻车现场5.1 编到一半报 C1060 或 C1001现象编译sqlite3.c过程中断输出fatal error C1060: compiler is out of heap space或者更糟直接fatal error C1001: INTERNAL COMPILER ERRORIDE 有时直接无响应。原因VC6 的编译器是 16 位时代的产物延续内部有硬编码的内存上限处理五兆以上的单个翻译单元时会撞上跟物理内存多少无关。开了/O2之后优化器还要额外吃内存更容易触发。解决C/C → Project Options 里追加/Zm1500编不过就往上加到/Zm2000。同时确认预编译头已经关掉预编译头会额外保留一份符号表占的内存不小。如果/Zm加到 2000 还报 C1001把优化级别临时降到/Od编一遍确认是优化器的问题后再逐个函数试。5.2 Debug 编得过Release 链接报 LNK2001现象Debug 配置下一切正常切到 Release 后链接阶段报unresolved external symbol _sqlite3_open但明明库文件名写对了路径也加了。原因两个库的运行时库选项不一致。工程里sqlite3.lib是用/MT编的而 Release 配置的业务工程用的是/MD。静态库的默认库依赖会带进链接器两边 CRT 版本冲突时链接器会把部分符号判为不可解析。解决把三个配置的运行时库统一。要么全部/MT静态链接 CRT发布时不用带 msvcrt.dll 的额外版本要么全部/MD。老工程我一般统一成/MT省得部署时因为目标机器缺运行库而起不来。改完必须把库和业务工程都完整重编一次只改一边没用。5.3 打开数据库返回 SQLITE_CANTOPEN路径看着没错现象sqlite3_open返回 14sqlite3_errmsg打印出来的路径跟代码里写的肉眼看着一致目录也确实存在权限也没问题。原因文件名编码不匹配。VC6 源码文件保存为 GBK字符串字面量是 GBK 字节流SQLite 按 UTF-8 解析中文目录名变成非法序列。纯英文路径不会触发所以很多人以为是“某个目录有问题”。解决改用sqlite3_open16传宽字符路径或者在调用前把路径转成 UTF-8。排查手段很简单把路径换成D:\\demo.db全英文试一次能打开就百分百是编码问题。5.4 运行几分钟后随机崩溃崩溃点不在数据库代码里现象程序跑一段时间后崩在free或HeapFree里调用栈跟 SQLite 完全无关日志里没有任何数据库报错。原因跨模块的内存分配与释放。sqlite3_mprintf、sqlite3_exec的错误信息字符串都是 SQLite 内部堆分配的如果库和主程序用了不同的 CRT一个/MT一个/MD两套堆管理器互不认识释放时踩坏堆结构崩溃点自然跑到别处。解决统一 CRT 选项同 5.2。另外养成习惯SQLite 分配的内存一律用配套的sqlite3_free释放不用freesqlite3_exec的错误信息用完必须sqlite3_free(errmsg)这条漏了就是稳定的小量泄漏跑一周能把工控机的内存吃干净。5.5 多线程下偶发 SQLITE_BUSY 或直接断言失败现象单线程测试全通过上了采集线程之后偶发SQLITE_BUSY偶尔直接崩在sqlite3_step内部。原因编库时SQLITE_THREADSAFE设成了 0或者设成 2 但把同一个sqlite3*句柄传给了另一个线程。模式 2 只保证不同连接之间安全同一连接仍然不能并发使用。解决先确认库的编译宏。设成 1 最稳妥序列化模式内部有互斥量同一句柄跨线程调用也安全。如果性能敏感必须用模式 2那就做连接池一个线程一个连接绝不共享句柄。另外sqlite3_busy_timeout一定要设否则写冲突时立刻返回错误业务层还得自己写重试循环。6. 装完怎么验证一个建表到查询的闭环库编出来了、工程链上了还得跑一遍能看见结果的闭环否则你永远不知道问题藏在哪一层。我在D:\sdk\sqlite3\build下单独建一个控制台工程做这件事不掺任何业务代码出问题好定位。#include stdio.h #include windows.h #include sqlite3.h int main(void) { sqlite3 *db NULL; sqlite3_stmt *stmt NULL; char *err NULL; int rc; /* 第一步用宽字符接口打开顺便验证中文路径这条路是通的 */ rc sqlite3_open16(LD:\\sdk\\sqlite3\\build\\验证.db, db); if (rc ! SQLITE_OK) { printf(open failed: %d\n, rc); return 1; } printf(version: %s\n, sqlite3_libversion()); /* 打印实际链接进来的版本 */ /* 第二步建表重复执行会报错属于预期行为忽略即可 */ sqlite3_exec(db, CREATE TABLE t(id INTEGER PRIMARY KEY, name TEXT, val REAL), NULL, NULL, err); sqlite3_free(err); err NULL; /* 第三步参数绑定插入避免拼接 SQL 带来的转义问题 */ rc sqlite3_prepare_v2(db, INSERT INTO t(name,val) VALUES(?,?), -1, stmt, NULL); if (rc SQLITE_OK) { sqlite3_bind_text(stmt, 1, demo, -1, SQLITE_STATIC); sqlite3_bind_double(stmt, 2, 3.14); rc sqlite3_step(stmt); printf(insert rc: %d (101 SQLITE_DONE)\n, rc); } sqlite3_finalize(stmt); /* 第四步查回来确认写入真的落盘而不是只在页缓存里 */ rc sqlite3_prepare_v2(db, SELECT id,name,val FROM t, -1, stmt, NULL); while (sqlite3_step(stmt) SQLITE_ROW) { printf(row: %d %s %.2f\n, sqlite3_column_int(stmt, 0), (const char*)sqlite3_column_text(stmt, 1), sqlite3_column_double(stmt, 2)); } sqlite3_finalize(stmt); sqlite3_close(db); return 0; }几个判定点。sqlite3_libversion()打出来的版本字符串必须跟你编库时用的源码版本对得上对不上说明链接到了系统里别的sqlite3.dll这是老机器上极常见的“幽灵依赖”PATH 里某个目录躺着一个旧 DLL链接器优先找到了它。SQLITE_DONE的数值是 101SQLITE_ROW是 100把这两个数值打出来比看宏名更直观日志里一眼能认出状态。第二步的建表语句故意不判断返回值因为重复跑第二次会返回“table already exists”这属于验证脚本的正常流程不是错误。第三步用参数绑定的原因不只是防注入更实际的是绕开中文转码问题绑定接口对SQLITE_STATIC的字符串不做拷贝字符串必须活到sqlite3_step之后。跑通之后再做一次关闭重开把程序结束重新启动直接跳到第四步查一次。能看到上次写进去的那行说明文件真的落盘了sqlite3_close也把日志刷干净了。这一条比任何单元测试都管用我见过不止一个工程因为没调sqlite3_close就直接TerminateProcessjournal 文件残留下次打开被判为损坏。从那以后我每次在老工程里接 SQLite都强制走一遍这套闭环打印版本号、宽字符打开、绑定插入、查回、关闭重开再查一次。五步走完剩下的业务代码才有讨论的基础。希望帮到你。本文还有配套的精品资源点击获取
简介面向仍在使用 Visual C 6.0 维护 Windows 老项目的开发者这套 SQLite3 源码与编译产物可省去自行移植、反复试错编译的麻烦。压缩包为 7z 格式体积约 5.4MB内含 VC6.0 工作空间与工程配置、编译得到的静态库与动态库以及用于验证功能的测试示例和对应版本参考文档工程配置齐全打开后即可复现构建过程也便于对照源码理解 SQLite3 的接口设计与内部实现属于偏进阶的底层数据库学习材料。已有 228 人学习下载多为需要兼容旧编译环境的团队。借助其中的库文件与示例代码读者可较快把这款轻量级关系型数据库接入既有工程完成数据存储与检索模块的搭建也可通过测试用例核对链接方式与运行表现排查静态库、动态库调用中的常见问题或在此基础上裁剪编译选项、做定制化改造。1. VC6 里塞进 SQLite3先把版本代差算清楚把 sqlite3 往 vc6.0 里装失败的概率比大多数人预估的高。某开发者接手一个 2003 年留下的 MFC 老工程想加个本地库存运行配置第一反应是把新下载的 amalgamation 包里的 sqlite3.c 直接拖进工程Build 一按输出窗口满屏 C2059、C2065编译器那个黑匣子里全是它不认识的语法。VC6 的编译器停在 C89 那一代SQLite 较新的分支早就默认 C99 起步中间隔着一整代工具的差距这不是改两个宏就能糊过去的。这类环境在工控上位机、老医疗设备、还有一堆没预算重写的桌面程序里依然常见装不好的表现要么是编不过要么是编过了运行期 sqlite3_open 返回 SQLITE_CANTOPEN。下面按我实际走通的顺序从挑版本、摆目录、编静态库到验证跑通一步步写。2. 挑版本和摆目录amalgamation 包在 VC6 下的取舍2.1 为什么不能直接上最新 amalgamationSQLite 官方给的那个 sqlite3.c 单文件包是把上百个源文件拼成一个翻译单元方便嵌入。这个设计对现代编译器很友好对 VC6 却是灾难文件体积大单个 .c 动辄五六兆VC6 的编译器前端在处理这种规模时会先把内存吃满语法层面又大量使用 C99 特性stdint.h、long long、块中间声明变量、变参宏VC6 一个都不认。我这边的判断标准很简单优先选 3.7.x 到 3.8.x 之间的 amalgamation 分支。这个区间的源码还保留着对老编译器的兼容分支sqlite3.h里对 MSVC 的_MSC_VER判断也覆盖到 1200 这一档——VC6 的_MSC_VER正好是 1200刚好卡在分支边界上属于能用但要看运气的位置。再往上的 3.3x 系列源码里已经默认stdint.h存在int64_t、uint32_t直接用VC6 编到一半就报fatal error C1083: Cannot open include file: stdint.h。如果你手上的业务代码已经依赖新版本的某个特性比如窗口函数或者 JSON1 扩展那我的建议是别在 VC6 里硬啃把 SQLite 的访问层抽成一个独立的 DLL用新编译器编VC6 侧只保留 C 接口调用。硬要把新源码塞进 VC6改到能编过的时间成本通常超过重写访问层。提示版本不是越新越好也不是越老越稳。3.6 之前的版本在 Windows 下的文件锁实现有已知缺陷多进程访问同一个库文件时容易出现锁不释放业务上一般避开。2.2 解压之后文件怎么摆amalgamation 包解开后是一堆文件实际要用的只有三个其余可以全部丢掉。我在 D 盘建一个固定目录所有老工程共用同一份源码和库避免每个工程各编一遍。D:\sdk\sqlite3\ ├── include\ │ ├── sqlite3.h # 唯一需要被业务工程 include 的头文件 │ └── sqlite3ext.h # 只写扩展模块才用普通业务不需要 ├── src\ │ └── sqlite3.c # 唯一的编译单元 ├── lib\ │ ├── sqlite3.lib # Release 静态库 │ └── sqlite3d.lib # Debug 静态库 └── build\ # VC6 工程文件与中间产物文件职责上要分清三件事。sqlite3.c是完整的实现编译它才产生符号sqlite3.h是接口声明业务工程 include 它sqlite3ext.h是给可加载扩展用的VC6 下通常直接关掉扩展加载能力这个头文件根本不会出现。包里如果带shell.c那是命令行工具的入口里面用了不少新语法VC6 编不过删掉不影响任何东西。一个容易忽略的点sqlite3.c里已经#include sqlite3.h所以编译时头文件搜索路径必须能找到同目录或指定目录下的sqlite3.h。最省事的做法是把sqlite3.h复制一份到src\下与.c同目录这样编译期和业务期用的是同一份头文件避免版本错位导致的结构体布局不一致。2.3 编译前必须定的几个预处理宏VC6 的工程设置里预处理宏是在 Project → Settings → C/C → Preprocessor → Preprocessor definitions 里填的。这几个宏决定了编出来的库长什么样改动之后必须整库重编不能只重编业务代码。宏建议值作用与取舍SQLITE_THREADSAFE11 为序列化模式多线程共用一个句柄也安全代价是每次调用加锁0 关闭全部互斥速度最快但只能单线程用2是多线程模式句柄不能跨线程共享SQLITE_OMIT_LOAD_EXTENSION定义关掉load_extensionVC6 下加载 DLL 的扩展路径基本用不上关掉能省一批符号SQLITE_OMIT_DEPRECATED定义去掉sqlite3_...那批废弃接口减小体积SQLITE_ENABLE_COLUMN_METADATA按需需要拿到结果列的原表名、库名时才开开了库会大一圈SQLITE_OS_WIN定义显式指定 Windows 后端VC6 下自动探测有时会走偏SQLITE_INT64_TYPE__int64版本里带这个入口时定义它直接绕开int64_t的类型定义问题SQLITE_THREADSAFE是最需要想清楚的一个。老上位机程序经常是 UI 线程写库、采集线程读库那就老老实实设成 1性能损失在毫秒级换来的是不用自己管句柄生命周期。如果整个程序只有一根线程碰数据库设成 0 能省下可观的开销但之后任何人加一根线程都会变成随机崩溃这种坑事后极难定位。3. 编静态库VC6 工程怎么建、选项怎么点3.1 新建 Win32 Static Library 工程不要图省事把sqlite3.c直接加进业务工程里一起编。业务工程每次改一行代码就要重编这个五兆的文件一次完整构建能拖到几分钟改到第十次就想砸键盘。单独建一个静态库工程编一次之后业务工程只链接.lib。操作路径是 File → New → Projects → Win32 Static Library工程名填sqlite3位置选D:\sdk\sqlite3\build。向导第二步会问要不要预编译头和 MFC 支持两个都不勾。建完之后在 FileView 里把sqlite3.c添加进 Source Filessqlite3.h添加进 Header Files。接着配两个 Build 配置。VC6 默认只有 Win32 Debug 和 Win32 ReleaseDebug 配置的输出文件名改成sqlite3d.libRelease 保持sqlite3.lib。业务工程在 Debug 下链接带 d 的那个Release 下链接不带 d 的两边必须严格对应。混用是后面链接错误的高发区我在第 5 章会细说。3.2 必须关掉的预编译头和必须打开的编译选项静态库工程默认会尝试使用预编译头而sqlite3.c里没有#include stdafx.h编译会直接报fatal error C1010: unexpected end of file while looking for precompiled header directive。在 Project → Settings → C/C → Precompiled Headers 里选 “Not using precompiled headers”两个配置都要改。其余选项在 C/C 面板里逐项确认# 等价于 VC6 工程设置里勾选的选项用命令行写出来更清楚 cl /nologo /c /W3 /O2 /MT /Zm1500 ^ /DSQLITE_THREADSAFE1 ^ /DSQLITE_OMIT_LOAD_EXTENSION ^ /DSQLITE_OMIT_DEPRECATED ^ /DSQLITE_OS_WIN ^ /FoRelease\sqlite3.obj ..\src\sqlite3.c lib /nologo /OUT:Release\sqlite3.lib Release\sqlite3.obj/c表示只编译不链接静态库工程本来就不做链接阶段。/W3是警告级别不建议开到/W4SQLite 内部有大量刻意为之的类型转换开高了满屏噪音反而盖住真正的错误。/O2是 Release 的优化级别Debug 配置换成/Od /Zi。/MT是静态链接 C 运行时这条最容易被忽略如果你的业务工程用的是/MD动态链接 CRT库和主程序会各自持有一份堆管理器和文件句柄表sqlite3_malloc分配的内存由主程序的free释放时行为未定义症状是偶发崩溃且崩溃点跟数据库逻辑毫无关系。/Zm1500是把编译器的内存分配上限提高到默认值的 1.5 倍。VC6 编译sqlite3.c这种体量的文件时默认上限经常不够报的是fatal error C1060: compiler is out of heap space机器内存再大也没用它卡的是编译器自己申请的那块堆。这个数值从 1000 起步往上试能编过就行开太大是浪费。/Fo指定目标文件输出路径lib命令在VC98\Bin目录下如果不在 PATH 里就用完整路径调用。3.3 编完之后核对该有的符号编出.lib不等于编对了还要确认里面真的有那几个核心符号。VC6 自带的dumpbin可以做这件事# 列出静态库里的全局符号过滤出核心接口 dumpbin /symbols Release\sqlite3.lib | findstr sqlite3_open sqlite3_exec sqlite3_prepare # 只看库里有哪些目标文件正常情况下应该只有一个 sqlite3.obj lib /list Release\sqlite3.lib第一条命令的输出里每个符号前面会带External和段号看到_sqlite3_open、_sqlite3_exec、_sqlite3_prepare_v2这几个就说明导出正常。如果全是UNDEF或者压根没输出通常意味着/c没生效或者源文件根本没被加入工程。第二条命令确认库里只有一个 obj有多个说明你误把别的源文件也加进了工程。Debug 配置编出来的sqlite3d.lib体积会明显大于 Release这是调试信息造成的正常现象不用管。但两边都要各编一次并各自核对别只验证 Release 就以为 Debug 也没问题。4. 让业务工程用上它包含路径、链接与字符集4.1 三个路径要写在哪业务工程需要知道三样东西的位置sqlite3.h在哪、sqlite3.lib在哪、编库时用了哪些宏。前两个在 Project → Settings 里配第三个经常被彻底忘掉。头文件路径C/C → Preprocessor → Additional include directories填D:\sdk\sqlite3\include库路径Link → Input → Additional library path填D:\sdk\sqlite3\lib库文件名Link → General → Object/library modules追加sqlite3.lib宏定义这一项业务工程侧不需要重复定义SQLITE_THREADSAFE这些。它们影响的是库内部的实现业务代码只消费sqlite3.h里的声明。但有一种情况必须同步如果你在编库时定义了SQLITE_ENABLE_COLUMN_METADATA业务代码里用到了sqlite3_column_table_name这类接口那头文件里也要有同样的宏否则声明不出现编译报未定义。我一般的做法是业务工程里也把这一组宏原样抄一份多写一行换来的是不用记哪些是“实现宏”、哪些是“接口宏”。4.2 链接的两个写法选一个就好写法一是在 Link 设置里手工加库名缺点是换个工程就要重配一遍容易漏。写法二是在代码里用#pragma comment把链接指令写进源码/* sqlite_link.h —— 业务工程统一引这个头别各处零散 include */ #ifndef SQLITE_LINK_H #define SQLITE_LINK_H /* VC6 的预处理器支持 #pragma comment链接时自动带上对应的库 */ #ifdef _DEBUG #pragma comment(lib, sqlite3d.lib) #else #pragma comment(lib, sqlite3.lib) #endif #include sqlite3.h #endif#pragma comment(lib, ...)是 MSVC 特有的指令VC6 完全支持。_DEBUG这个宏由 IDE 在 Debug 配置下自动定义所以 Debug 和 Release 会自动选到不同的库省掉手工切换的麻烦。前提是库搜索路径已经加进 Link 的 Additional library path否则会报LINK : fatal error LNK1104: cannot open file sqlite3d.lib。这种写法还有个隐性好处把链接依赖和头文件包含绑在一起新人拿到工程不会出现“头文件找到了但库里没链接”的半吊子状态。4.3 中文路径一次从 ANSI 到 UTF-16 的转换这是 VC6 用 SQLite 最容易踩且最难查的一条。sqlite3_open接收的是 UTF-8 编码的文件名而 VC6 默认按 ANSI简体中文环境下是 GBK 代码页编译字符串字面量。程序里写sqlite3_open(D:\\数据\\demo.db, db)传进去的是 GBK 字节流SQLite 按 UTF-8 解析路径直接变成乱码返回值是SQLITE_CANTOPEN而错误信息里显示的路径看着“差不多对”特别迷惑。最省事的解法是改用宽字符接口sqlite3_open16#include windows.h #include sqlite3.h /* 封装一层业务侧只传宽字符路径避免每次手工转码 */ sqlite3* open_db_utf16(const wchar_t *wpath) { sqlite3 *db NULL; /* sqlite3_open16 接收 UTF-16 字符串VC6 支持 L 宽字符字面量 */ int rc sqlite3_open16(wpath, db); if (rc ! SQLITE_OK) { /* 打开失败时 db 可能非空必须关掉否则每次重试漏一个句柄 */ if (db) { sqlite3_close(db); db NULL; } return NULL; } /* 顺手把忙等待超时设上默认 0 意味着一撞锁立刻返回 SQLITE_BUSY */ sqlite3_busy_timeout(db, 3000); return db; }sqlite3_open16的第二个参数是sqlite3**输出第一参数是const void*实际传宽字符串指针。sqlite3_busy_timeout设成 3000 毫秒意思是遇到写锁被占用时最多等三秒再返回错误默认值是 0多线程或多进程环境下会频繁拿到SQLITE_BUSY很多“偶发写入失败”的报障都是这个默认值引起的。要注意这个封装只解决了文件名的编码问题。SQL 语句本身的文本sqlite3_exec和sqlite3_prepare仍然按 UTF-8 解释。如果 SQL 里要写中文常量比如INSERT INTO t VALUES(测试)得先把这段 SQL 从 GBK 转成 UTF-8用MultiByteToWideChar转 UTF-16 再WideCharToMultiByte转 UTF-8 两步走不能直接一步从 936 转到 65001那条路径在部分系统上会丢字符。老工程的通行做法是把所有中文常量改成绑定参数sqlite3_bind_text前统一转码逻辑更干净。5. 避坑记录VC6 编 SQLite3 的五个翻车现场5.1 编到一半报 C1060 或 C1001现象编译sqlite3.c过程中断输出fatal error C1060: compiler is out of heap space或者更糟直接fatal error C1001: INTERNAL COMPILER ERRORIDE 有时直接无响应。原因VC6 的编译器是 16 位时代的产物延续内部有硬编码的内存上限处理五兆以上的单个翻译单元时会撞上跟物理内存多少无关。开了/O2之后优化器还要额外吃内存更容易触发。解决C/C → Project Options 里追加/Zm1500编不过就往上加到/Zm2000。同时确认预编译头已经关掉预编译头会额外保留一份符号表占的内存不小。如果/Zm加到 2000 还报 C1001把优化级别临时降到/Od编一遍确认是优化器的问题后再逐个函数试。5.2 Debug 编得过Release 链接报 LNK2001现象Debug 配置下一切正常切到 Release 后链接阶段报unresolved external symbol _sqlite3_open但明明库文件名写对了路径也加了。原因两个库的运行时库选项不一致。工程里sqlite3.lib是用/MT编的而 Release 配置的业务工程用的是/MD。静态库的默认库依赖会带进链接器两边 CRT 版本冲突时链接器会把部分符号判为不可解析。解决把三个配置的运行时库统一。要么全部/MT静态链接 CRT发布时不用带 msvcrt.dll 的额外版本要么全部/MD。老工程我一般统一成/MT省得部署时因为目标机器缺运行库而起不来。改完必须把库和业务工程都完整重编一次只改一边没用。5.3 打开数据库返回 SQLITE_CANTOPEN路径看着没错现象sqlite3_open返回 14sqlite3_errmsg打印出来的路径跟代码里写的肉眼看着一致目录也确实存在权限也没问题。原因文件名编码不匹配。VC6 源码文件保存为 GBK字符串字面量是 GBK 字节流SQLite 按 UTF-8 解析中文目录名变成非法序列。纯英文路径不会触发所以很多人以为是“某个目录有问题”。解决改用sqlite3_open16传宽字符路径或者在调用前把路径转成 UTF-8。排查手段很简单把路径换成D:\\demo.db全英文试一次能打开就百分百是编码问题。5.4 运行几分钟后随机崩溃崩溃点不在数据库代码里现象程序跑一段时间后崩在free或HeapFree里调用栈跟 SQLite 完全无关日志里没有任何数据库报错。原因跨模块的内存分配与释放。sqlite3_mprintf、sqlite3_exec的错误信息字符串都是 SQLite 内部堆分配的如果库和主程序用了不同的 CRT一个/MT一个/MD两套堆管理器互不认识释放时踩坏堆结构崩溃点自然跑到别处。解决统一 CRT 选项同 5.2。另外养成习惯SQLite 分配的内存一律用配套的sqlite3_free释放不用freesqlite3_exec的错误信息用完必须sqlite3_free(errmsg)这条漏了就是稳定的小量泄漏跑一周能把工控机的内存吃干净。5.5 多线程下偶发 SQLITE_BUSY 或直接断言失败现象单线程测试全通过上了采集线程之后偶发SQLITE_BUSY偶尔直接崩在sqlite3_step内部。原因编库时SQLITE_THREADSAFE设成了 0或者设成 2 但把同一个sqlite3*句柄传给了另一个线程。模式 2 只保证不同连接之间安全同一连接仍然不能并发使用。解决先确认库的编译宏。设成 1 最稳妥序列化模式内部有互斥量同一句柄跨线程调用也安全。如果性能敏感必须用模式 2那就做连接池一个线程一个连接绝不共享句柄。另外sqlite3_busy_timeout一定要设否则写冲突时立刻返回错误业务层还得自己写重试循环。6. 装完怎么验证一个建表到查询的闭环库编出来了、工程链上了还得跑一遍能看见结果的闭环否则你永远不知道问题藏在哪一层。我在D:\sdk\sqlite3\build下单独建一个控制台工程做这件事不掺任何业务代码出问题好定位。#include stdio.h #include windows.h #include sqlite3.h int main(void) { sqlite3 *db NULL; sqlite3_stmt *stmt NULL; char *err NULL; int rc; /* 第一步用宽字符接口打开顺便验证中文路径这条路是通的 */ rc sqlite3_open16(LD:\\sdk\\sqlite3\\build\\验证.db, db); if (rc ! SQLITE_OK) { printf(open failed: %d\n, rc); return 1; } printf(version: %s\n, sqlite3_libversion()); /* 打印实际链接进来的版本 */ /* 第二步建表重复执行会报错属于预期行为忽略即可 */ sqlite3_exec(db, CREATE TABLE t(id INTEGER PRIMARY KEY, name TEXT, val REAL), NULL, NULL, err); sqlite3_free(err); err NULL; /* 第三步参数绑定插入避免拼接 SQL 带来的转义问题 */ rc sqlite3_prepare_v2(db, INSERT INTO t(name,val) VALUES(?,?), -1, stmt, NULL); if (rc SQLITE_OK) { sqlite3_bind_text(stmt, 1, demo, -1, SQLITE_STATIC); sqlite3_bind_double(stmt, 2, 3.14); rc sqlite3_step(stmt); printf(insert rc: %d (101 SQLITE_DONE)\n, rc); } sqlite3_finalize(stmt); /* 第四步查回来确认写入真的落盘而不是只在页缓存里 */ rc sqlite3_prepare_v2(db, SELECT id,name,val FROM t, -1, stmt, NULL); while (sqlite3_step(stmt) SQLITE_ROW) { printf(row: %d %s %.2f\n, sqlite3_column_int(stmt, 0), (const char*)sqlite3_column_text(stmt, 1), sqlite3_column_double(stmt, 2)); } sqlite3_finalize(stmt); sqlite3_close(db); return 0; }几个判定点。sqlite3_libversion()打出来的版本字符串必须跟你编库时用的源码版本对得上对不上说明链接到了系统里别的sqlite3.dll这是老机器上极常见的“幽灵依赖”PATH 里某个目录躺着一个旧 DLL链接器优先找到了它。SQLITE_DONE的数值是 101SQLITE_ROW是 100把这两个数值打出来比看宏名更直观日志里一眼能认出状态。第二步的建表语句故意不判断返回值因为重复跑第二次会返回“table already exists”这属于验证脚本的正常流程不是错误。第三步用参数绑定的原因不只是防注入更实际的是绕开中文转码问题绑定接口对SQLITE_STATIC的字符串不做拷贝字符串必须活到sqlite3_step之后。跑通之后再做一次关闭重开把程序结束重新启动直接跳到第四步查一次。能看到上次写进去的那行说明文件真的落盘了sqlite3_close也把日志刷干净了。这一条比任何单元测试都管用我见过不止一个工程因为没调sqlite3_close就直接TerminateProcessjournal 文件残留下次打开被判为损坏。从那以后我每次在老工程里接 SQLite都强制走一遍这套闭环打印版本号、宽字符打开、绑定插入、查回、关闭重开再查一次。五步走完剩下的业务代码才有讨论的基础。希望帮到你。本文还有配套的精品资源点击获取
