简介：Absolute Database v7.93 源代码面向使用 Delphi 4 至 11 的数据库开发者与进阶学习者，提供可编译、可研究的对象关系型数据库引擎实现，支持数值、字符串、日期时间及自定义类型，并优化大数据量读写性能，可用于理解事务处理、内存缓存、权限加密、备份恢复及多用户并发等机制，也便于按企业项目需求二次开发。压缩包共 756 个文件、约 18.9MB，含 SQL 脚本、Pascal 与 C++ 源码、DCU 编译单元、DFM 窗体、DPK 包工程及 C/OBJ/RES 资源，覆盖引擎源码、组件库、示例工程与设计时支持，目录便于按模块查阅。已有 446 人学习或下载。借助完整源代码，读者可追踪数据库底层实现，对照 IDE 组件集成方式，并参考数据迁移、跨平台部署与多用户场景做定制优化；对维护旧版 Delphi 项目或研究数据库引擎结构的中高级开发者较有价值。
1. 先说结论：这套源码包解决的是「Delphi 程序不想装服务端数据库」的硬需求
接手一个还在用 Delphi 维护的老业务系统，客户机是内网工控机，装不了也不允许装任何数据库服务，需求只有一句「数据落本地、还要能 SQL 查」。这种场景里，Absolute Database v7.93 的 sources for D4-11 源码包是个很实际的选择：它是一套纯 Delphi 实现的嵌入式数据库组件，编译进 exe 就跑，不依赖 BDE、不依赖 ADO、不需要额外安装服务端进程，数据落在一个单文件里，上层依旧走 TDataSet 那一套——Dataset、DataSource、DBGrid 照常接。源码包的意义在于版本覆盖广，从 Delphi 4 一直照顾到 11，老工程不用为了换个数据库去改编译器版本。
适合谁：手上维护 D4～D11 任一版本工程、需要本地库但不想背部署负担的从业者；想读实现、想按自己业务改存储层的人；以及要做离线单机版交付、又必须支持事务和索引的项目。不适合谁：多人高并发写入、要做主从、要跑在集群上的系统，那不是它的赛道。
2. 编译与安装：把 v7.93 源码落进 D4–D11 的 IDE
拿到源码包的第一反应通常是双击 .dpr 打开就编译，这一步在 D4～D7 上基本能过，在 D2009 之后大概率报一屏错。原因不复杂：源码里到处是{$IFDEF UNICODE}、{$IFDEF VERxxx}这类条件编译开关，而这些开关必须由对应版本的编译器喂进去，用错版本的 dcc32 去编，宏判断走的分支就是错的。所以顺序应该是先分清版本代际，再决定用哪条命令编译，最后才谈 IDE 安装。
2.1 先看目录结构，确定要编哪几个包
解压之后常见做法是分成这么几块，我按自己被坑过的经验列一下，你对照手里的包核一下名字：
| 目录 | 内容 | 处理方式 |
|---|---|---|
src | 核心单元，数据集、SQL 解析、存储引擎 | 加入 Library Path，不单独编译 |
packages | 运行期包与设计期包（.dpk） | 按编译器版本选对应 .dpk 编译 |
demos | 示例工程与 SQL 脚本 | 先跑通 demo，验证编译产物正确 |
doc | 接口说明与版本变更记录 | 查字段类型和 SQL 支持范围最快 |
关键是packages下通常会有按版本分组的 .dpk，不要图省事拿最高版本的包去低版本 IDE 里装。设计期包（Design-time）只负责把组件注册到工具面板，运行期包（Runtime）才是真正要被 exe 引用的东西，两者编译目标平台必须一致，Win32 配 Win32，别混。
提示：源码包里如果有预编译好的 .dcu，先别用。预编译产物和你的编译器版本、编译选项（尤其是范围检查、溢出检查开关）必须严格一致，否则会出现运行期莫名其妙的访问越界。
2.2 用命令行先做一次干净编译
不管后面装不装 IDE，我都建议先在命令行跑通一次完整编译，把「环境问题」和「代码问题」分开。D2005 之后走 msbuild，D4～D7 只能走 dcc32，两条路线分开写。
# D2005 及以后（含 D11）：在 packages 目录下，指定配置和目标平台 msbuild AbsoluteDB_Run.dproj /t:Build /p:Config=Release /p:Platform=Win32 /v:minimal # 想同时产出 64 位，再跑一遍，注意 .dproj 里必须已经声明了 Win64 平台 msbuild AbsoluteDB_Run.dproj /t:Build /p:Config=Release /p:Platform=Win64 /v:minimal# D4 ~ D7：dcc32 直接编 .dpk，-B 强制全量重编，-U 指定单元搜索路径，-I 指定 include 路径 dcc32 -B ^ -U"..\src;..\src\common" ^ -I"..\src" ^ -LE"..\lib" ^ -LN"..\lib" ^ AbsoluteDB_Run.dpk命令里的参数含义值得说清楚：-B是忽略已有 .dcu 全量重编，这是排错时最有用的一把钥匙，很多「明明改了源码却没生效」的问题都是增量编译缓存造成的；-U给的是单元搜索路径，源码包内部单元互相引用靠它；-LE/-LN分别指定 .bpl 和 .dcp 的输出目录，把它们统一收到一个 lib 目录，后面配 IDE 路径会省事很多。编译完看输出目录有没有生成 .bpl，再顺手看一眼有没有 warning 级别的隐式字符串转换提示——在 Unicode 版本上，这类警告往往就是后面中文乱码的源头。
2.3 装进 IDE 与版本取舍
编译产物齐了之后，IDE 里走Component → Install Packages → Add，选中设计期那个 .bpl，组件面板出现对应页签就算成功。这一步翻车最多的情况是「装上了但一放组件就报找不到单元」，本质是 IDE 的 Library Path 没指到src。手工加一次：Tools → Options → Language → Delphi → Library，把src目录加进搜索路径，Win32 和 Win64 两套路径要分别加，很多人只加了 32 位那套，一切 64 位目标就崩。
版本取舍上有几个真实边界要认：
- D4～D7 只有 Win32，且默认字符串是 AnsiString，源码里的
string就是单字节，处理中文要确保代码页一致（通常 GBK），跨机器拷贝数据文件时最容易在这里出问题。 - D2009 是分水岭，
string变成 UnicodeString。如果你的老工程是 D7 写的、中间升到 D11，源码包里字段的字符类型映射会跟着变，同一个 VARCHAR 字段在不同编译器版本下取出来的字符串类型不一样，赋值给AnsiString变量就会截断。 - 64 位目标下指针宽度变了，源码里如果有
Integer(Pointer)这类强转，会在 64 位下高位截断。这类地方编译期不一定报错，运行期崩，属于典型黑匣子问题。
我的习惯是：先只编 Win32、只跑 demos 里最简单的那个例子，确认能建库、能读写、中文不乱码，再去碰 64 位。一步一步来，比一次性全平台编译然后对着一屏错误猜要快得多。
3. 数据模型落地：从组件到第一张表的完整链路
源码编译通过只是「能跑」，真正落地要解决的是「表怎么建、字段怎么映射、SQL 支持到哪」。这套库是文件型的，一个数据库就是一个文件（常见扩展名是 .ads 或 .abs，以你手里源码的默认值为准），没有服务端、没有实例概念，所有 DDL 和 DML 都直接对着这个文件做。理解这一点，后面很多限制就顺了：没有服务端连接池，没有跨库 JOIN（除非用它的 attach 机制），也没有 DBA 帮你做在线备份。
3.1 连接配置与单文件库的物理约束
数据集组件的连接信息通常就是「数据库文件名 + 可选的用户名密码」。这里有个容易被忽略的点：相对路径是相对于进程当前工作目录，不是相对于 exe 所在目录。用ShellExecute从别处启动、或者被计划任务拉起时，工作目录可能完全不是你预期的那个，结果就是「程序在开发机上好好的，装到客户机上就提示找不到库，然后它默默新建了一个空库」——这个坑我踩过，客户数据全空，血泪经验。
// 用绝对路径构造库文件位置，避免工作目录漂移导致的"新建空库" function BuildDbPath(const AppDir, DbName: string): string; begin // 统一走 exe 所在目录下的 data 子目录，不依赖 GetCurrentDir Result := IncludeTrailingPathDelimiter(AppDir) + 'data' + PathDelim + DbName; // 目录不存在时先建，否则打开会失败 ForceDirectories(ExtractFileDir(Result)); end;上面这段没有用到任何数据库 API，但它决定了后面所有代码的行为边界。参数说明：AppDir一般传ExtractFilePath(ParamStr(0))；DbName建议带固定扩展名，不要留空让驱动去猜。养成这个习惯之后，「找不到库」这类问题在我这儿基本绝迹。
另外要提前想清楚单文件库的三个物理事实：文件会随数据增长而变大，删数据后空间不一定立刻还给操作系统，需要显式做整理（常见做法是导出重建或者调用组件自带的压缩方法，具体名字看你那份源码的接口声明）；备份就是复制文件，但必须在没有写入连接的时候复制，热复制大概率拿到不一致的快照；文件放在网络共享盘上，多机同时打开时的锁语义完全依赖操作系统的文件锁，延迟一高就会出现「写不进去也不报错」的玄学现象。
3.2 建表、建索引与 SQL 方言的三条边界
SQL 支持范围这件事，别信任何二手资料，直接翻demos目录里的 SQL 脚本，那是跟源码同版本、可信度最高的样本。按一般经验，标准 DDL 和基本 DML 是稳的，复杂特性就要试。
-- 建主表：主键、非空、默认值都给全，别指望运行期补 CREATE TABLE T_ORDER ( ID INTEGER NOT NULL PRIMARY KEY, ORDER_NO VARCHAR(32) NOT NULL, CUSTOMER_ID INTEGER, AMOUNT NUMERIC(18,4), STATUS SMALLINT DEFAULT 0, CREATED_AT TIMESTAMP, MEMO_TEXT TEXT, ATTACH BLOB ); -- 查询条件里最常出现的两列，各建一个单列索引 CREATE INDEX IDX_ORDER_NO ON T_ORDER (ORDER_NO); CREATE INDEX IDX_ORDER_TIME ON T_ORDER (CREATED_AT);建表这一步有三条边界值得盯：
第一，字段类型映射。INTEGER、SMALLINT、VARCHAR(n)、NUMERIC(p,s)、TIMESTAMP、TEXT、BLOB这几类在大多数嵌入式库里都支持，但BOOLEAN、GUID、自动增长字段的支持程度差异很大。自动增长尤其要试——如果它不支持 identity，就得自己在应用层发号，而且要考虑断电重启后的号段接续，这是设计期必须定下来的事。
第二，索引与排序。ORDER BY能不能走索引，取决于优化器实现，简单库里优化器往往很朴素。判断方法很土但有效：造十万行数据，对比有索引和无索引时带ORDER BY的查询耗时，差一个数量级就说明走了索引。
第三，NULL 语义。有些嵌入式库对NULL的比较行为跟标准 SQL 不一致，WHERE COL <> 1在标准里会排除 NULL 行，在某些实现里不会。这类差异不做实验根本发现不了，建议在项目初期就写一条断言脚本把这类行为固定下来。
3.3 参数化查询与 BLOB 字段的读写姿势
只要涉及用户输入，就必须参数化，这一点没有商量余地。拼字符串不只是注入风险，更现实的问题是日期、小数点的格式在不同区域设置下不一样，拼出来的 SQL 在客户机上就是语法错误。
// 参数化插入：类型明确赋值，不要用 AsString 硬塞数字 Q.Close; Q.SQL.Text := 'INSERT INTO T_ORDER (ID, ORDER_NO, CUSTOMER_ID, AMOUNT, CREATED_AT) ' + 'VALUES (:ID, :ORDER_NO, :CUSTOMER_ID, :AMOUNT, :CREATED_AT)'; Q.ParamByName('ID').AsInteger := NewOrderId; Q.ParamByName('ORDER_NO').AsString := Trim(edtOrderNo.Text); Q.ParamByName('CUSTOMER_ID').AsInteger := CustId; Q.ParamByName('AMOUNT').AsCurrency := StrToCurrDef(edtAmount.Text, 0); Q.ParamByName('CREATED_AT').AsDateTime := Now; Q.ExecSQL;逻辑说明：Close再改SQL.Text是必须的，数据集处于打开状态时改 SQL 在部分实现里会静默失败；参数按:前缀绑定，名字大小写一般不敏感但建议保持一致；AsCurrency而不是AsFloat是关键，金额字段用浮点存、跨机器比对时会差一分钱，这种 bug 排查起来极其难受。参数说明：NewOrderId建议来自一个独立号段表而不是Max(ID)+1，多客户端并发时后者必然重号。
BLOB 读写要用流，不要试图转成字符串：
// 读 BLOB 到文件，走 CreateBlobStream，避免一次性读进内存 var FS: TFileStream; BS: TStream; begin Q.Close; Q.SQL.Text := 'SELECT ATTACH FROM T_ORDER WHERE ID = :ID'; Q.ParamByName('ID').AsInteger := OrderId; Q.Open; if not Q.IsEmpty then begin FS := TFileStream.Create(SavePath, fmCreate); try BS := Q.CreateBlobStream(Q.FieldByName('ATTACH'), bmRead); try FS.CopyFrom(BS, 0); // 第二参数 0 表示拷到流末尾 finally BS.Free; end; finally FS.Free; end; end; end;CopyFrom第二个参数传 0 是「拷到源流结束」，这个语义在多数 TStream 实现里成立。如果附件动辄几十兆，建议在表里单独存一个附件表、每次只按 ID 取一条，别在主表 SELECT 里带 BLOB 列——SELECT *把 BLOB 一起拉出来是这类库最常见的性能自杀方式。
4. 事务与并发：两个进程同时打开同一个库文件会发生什么
这是这套方案里最需要提前想清楚的部分。它是文件型库，所谓「并发」本质是多个进程通过操作系统的文件锁去协调，跟服务端数据库的行锁、MVCC 完全不是一个量级。开发阶段单进程跑，一切正常；上了多客户端共享目录，问题会集中爆发。
4.1 事务边界怎么划才不锁死
事务的基本套路是StartTransaction / Commit / Rollback，难点不在 API 而在边界。我的一般原则是：一个业务动作一个事务，事务里只放数据库操作，不放任何 UI 交互、文件 IO、网络调用。
// 事务骨架：异常必须回滚，且不要在事务内弹框 DB.StartTransaction; try // 1. 写主表 Q1.Close; Q1.SQL.Text := 'UPDATE T_ORDER SET STATUS = :S WHERE ID = :ID'; Q1.ParamByName('S').AsInteger := 2; Q1.ParamByName('ID').AsInteger := OrderId; Q1.ExecSQL; // 2. 写流水表 Q2.Close; Q2.SQL.Text := 'INSERT INTO T_ORDER_LOG (ID, ORDER_ID, ACTION) ' + 'VALUES (:ID, :ORDER_ID, :ACTION)'; Q2.ParamByName('ID').AsInteger := NewLogId; Q2.ParamByName('ORDER_ID').AsInteger := OrderId; Q2.ParamByName('ACTION').AsString := 'CONFIRM'; Q2.ExecSQL; DB.Commit; except on E: Exception do begin DB.Rollback; raise; // 交给上层统一记日志，事务层不吞异常 end; end;事务对象挂在数据集的哪个属性上（Database、Session还是独立的事务组件），按你手里源码的实际声明来，这类嵌入式库的做法不完全统一。参数说明：Rollback之后必须raise，把异常抛给调用方，否则事务失败会被静默吞掉，上层以为成功了。还有一个反直觉的点——事务里不要做ShowMessage，模态框会把整个事务的持锁时间拉长到用户点确定为止，多客户端场景下这就是一次锁等待雪崩。
4.2 并发写冲突的三种典型表现
按我这边的排查记录，多进程写同一个库时，症状基本落在三类里：
第一种，写操作抛异常，提示锁冲突或记录被占用。这是最友好的情况，至少它告诉你了。处理方式是加重试：捕获异常、Sleep(50~200)随机抖动、重试 3 次，仍失败就上报。抖动很重要，固定间隔重试会让两个客户端同步撞车。
第二种，写操作不报错但数据没进去。多见于网络盘或者文件被别的进程以独占方式打开过。判断方法是写完立刻在同一个连接里读回来比对，别信ExecSQL的返回值。
第三种，读到的数据是旧值。这通常不是并发问题，是数据集缓存。TDataSet有自己的记录缓冲，Refresh没调、或者Close/Open没走，看到的永远是打开那一刻的快照。在列表页停留很久再点「查看详情」，看到旧数据就是这个原因。
注意：不要用「文件是否存在」来判断数据库是否可用。这类库在打开时会创建附属的临时文件或锁文件，用文件存在性做健康检查会得到完全错误的结论，正确做法是真发一条
SELECT出去。
4.3 数据目录与权限：把库放在网络盘上是最后的选项
单机部署是最稳的形态：库文件在本地磁盘，只有一个进程写，事务和锁的压力最小。多客户端共享，比较稳的做法是「一人一个库文件 + 定期汇总」，而不是所有人抢一个文件。
如果业务上必须共享，那就得接受三个前提：共享目录权限要放开到修改级（只读权限会导致写失败但不一定报错）；网络延迟要低，任何超过几十毫秒的抖动都会放大锁等待；文件服务器不能做激进的文件缓存，某些缓存策略会让多个客户端看到不一致的文件视图。
还有一个部署细节：程序目录一般装在Program Files下，普通用户对该目录没有写权限。库文件放这里，程序会表现为「能查询、不能保存」。解决办法是把数据目录挪到ProgramData或者用户目录下，第一次启动时用ForceDirectories建出来。这个坑在开发机（管理员账户）上永远复现不了，一到客户现场就全员中招。
5. 避坑清单：这类嵌入式库最容易翻车的 5 个点
5.1 编译与安装期的两个坑
现象一：设计期装好了，一放组件到窗体就报「找不到单元 xxx」。原因：IDE 的 Library Path 只加了 Win32 那一套，或者加的是src的父目录而不是src本身；切到 Win64 目标时路径没同步。 解决：分别给 Win32 和 Win64 配路径，配完关掉 IDE 重开（路径缓存有时候不刷新），再用一个空工程放一个组件编译一次验证。别在原有的大工程里试，干扰因素太多。
现象二：编译通过，运行时报「无效的 .dcu 版本」或莫名其妙的访问越界。原因：目录里混进了别的 Delphi 版本预编译的 .dcu，增量编译时被误用；或者范围检查、溢出检查开关跟编译 .dcu 时不一致。 解决：删掉所有 .dcu 做一次全量重编（dcc32 加-B，IDE 里用Build而不是Compile）。这一步看着笨，但能清掉一大半玄学问题。
5.2 运行期的三个坑
现象三：客户机上程序能查不能存，也不报错。原因：库文件所在目录对当前用户没有写权限（典型是装在Program Files下）。 解决：数据目录独立出来，首次启动时建目录并做一次写探测——写一个临时文件、删掉，失败就提示用户换目录。别等到用户点了保存才发现。
现象四：中文变成问号或者乱码，尤其在 D7 老工程升到 D11 之后。原因：字段是单字节存储，代码在 Unicode 编译器下用AnsiString接值，转换时按默认代码页截断；或者建库时的字符集设置跟读取时不一致。 解决：全链路统一用string（Unicode 版本下即 UnicodeString），只在最外层跟外部系统交互时才做显式编码转换，并且转换时明确指定代码页，不依赖系统默认。
现象五：数据文件越来越大，删了数据也不见小。原因：文件型库的页分配策略是复用而非归还，删除只是把页标记为空闲。 解决：设定一个阈值（比如空闲率超过 30%），在业务低峰期做一次整理：导出到新库、切换、保留旧库一段时间。整理期间必须独占，别在营业时间做。
6. 迁移与回归：把旧库搬到 v7.93 上，我固定走这四步
老项目升级，最怕的不是编不过，是「编过了、数据搬过去了、跑了一周才发现某张表的金额字段少了一位小数」。所以我的迁移流程是固定的，一步都不跳。
第一步，结构比对。用两边的元数据查询把表名、字段名、类型、精度、是否为空、默认值全导出来，落到一张对照表里人工过一遍。重点看NUMERIC的精度和小数位、VARCHAR的长度、时间字段是DATE还是TIMESTAMP。精度从(18,4)被读成(18,2)这种，迁移脚本不会报错，只会在某天对账时炸出来。
第二步，数据搬运走「读—写—校验」三段式，不用批量工具一把梭。每批 500 行，写完立刻按主键回读比对，比对字段包括所有数值列和长度敏感的字符列。
| 校验项 | 方法 | 判定标准 |
|---|---|---|
| 行数 | 源表 count vs 目标表 count | 必须完全相等 |
| 金额类 | 按主键抽样 5%，逐行比对 | 差值为 0，不接受「误差范围内」 |
| 字符类 | 比对长度与首尾字符 | 长度相等且无截断 |
| 时间类 | 比对到秒 | 时区偏移必须为 0 |
| BLOB | 比对字节长度 + MD5 | 完全一致 |
第三步，回归验证跑真实业务路径，不跑自己写的测试用例。挑三个客户最常用的操作，从界面点进去，一路点到导出报表，全程开 SQL 日志看实际下发的语句。这一步能抓到 90% 的方言问题——比如某个LEFT JOIN在旧库上能跑，新库的解析器不认，或者ORDER BY用了别名。
第四步，灰度。先给一个客户装，观察一周。这一周里我只看两件事：一是错误日志里跟数据库相关的异常数量，二是每天定时任务跑完后的对账结果。两项都平稳，再推第二批。
从那以后我每次做这类库升级，都强制走一遍「元数据比对 + 抽样回读 + 真实路径回归」这三件套，哪怕客户催得再急也不省——省下来的两天，往往要用两周的线上排障去还。这套 v7.93 的源码包本身质量是够用的，翻车基本都翻在环境、权限和迁移细节上，把这几处摁住，它能安安静静跑很多年。需要这份源码包的话，按标题里的名字去找对应版本就行，注意核对支持的编译器代际，别拿 D11 的包往 D7 上装。希望帮到你。
本文还有配套的精品资源，点击获取
