简介在桌面与移动端应用开发中嵌入式数据库因免部署、轻量高效而成为本地数据存储的首选。SQLite作为广泛使用的C语言数据库引擎通常需要借助第三方组件才能在Delphi中便捷调用。DISQLite3正是这样一款将SQLite完整封装为Delphi原生类的控件它无需额外DLL支持VCL与FireMonkey框架并内置AES加密能力适合构建离线缓存、PDA扫码、工控数据采集等场景。从环境配置到组件安装从基础的增删改查到事务优化、跨平台路径处理再到与System.Hash、System.JSON的联动本文围绕Delphi 11/12 Athens下的工程实践梳理了数据库连接、性能调优及常见问题排查方法帮助开发者快速构建稳定、安全、可交付的本地数据库应用并自然聚焦到DISQLite3这一成熟组件的实际应用价值上。1. 为什么我还在用DISQLite3一个老牌Delphi SQLite控件的价值所在先说结论在Delphi生态里做本地嵌入式数据库DISQLite3是我个人最顺手的选择之一尤其是你正在用Delphi 11或12 Athens这两个版本。它不是新的库但它足够成熟几乎覆盖了SQLite的绝大部分能力同时API封装得比FireDAC自带的SQLite驱动更接地气没有那一堆底层的类要学组件一拖连接一开Select一写数据就出来了。DISQLite3本质上是一个面向Delphi/FireMonkey的SQLite嵌入式数据库组件包。它的核心特点是把SQLite这个C语言写的数据库引擎完整封装成了Delphi原生类因此不需要你在系统里额外安装SQLite的DLL也不需要在发布程序时带上一个sqlite3.dll文件。这个特性在桌面端可能觉得无所谓但放到移动端、放到那种客户现场只有一台裸机Windows的部署场景里价值一下就出来了。没有外部依赖意味着程序拷过去就能跑减少了大量莫名其妙的环境问题。适合谁看我分成三类人。第一类是在Delphi 7、XE2、10.x时代就在用第三方SQLite组件现在升级到Delphi 12 Athens正愁原来那套控件在新IDE里编译不过、跑不起来、注册不了的老开发者。第二类是刚接触Delphi想给FireMonkey程序加一个本地数据库但又不想碰FireDAC那一长串配置的新手。第三类是在做PDA、工控机、嵌入式终端这类小屏幕设备程序的人——因为DISQLite3在FireMonkey下的表现相当稳定而且没有运行时依赖非常适合这种受限环境。我用这个控件写过库存盘点PDA程序写过工厂设备参数记录工具也写过Windows桌面端的离线数据采集器。说实话它不算花哨但胜在稳。这年头控件不在多在于不出幺蛾子。DISQLite3给我最大的感受就是装上之后忘掉它存在安心写业务。但我也要先把话说明白如果你下载的包里带了CRACK字样请直接删除去官方买正版授权或者先下载官方评估版做技术验证。开发工具的破解是一个大坑轻则控件稳定性没有保障重则编译出来的程序运行时出现随机崩溃、数据损坏最终坑的是自己的交付质量。本文所有内容都是基于正版授权或官方评估版的常见做法来写的这不是说教是被坑过之后的心得。2. 开始之前Delphi 12 Athens环境下的准备与安装2.1 确认你的Delphi版本和控件兼容性DISQLite3 v5.48.3这个版本从命名上可以看出它是为Delphi 11和Delphi 12 Athens准备的。Delphi 12的代号就是Athens所以你在网上搜Delphi Athens控件包的时候很多库会明确标注for Delphi 11-12 Athens这表示该版本组件包已经针对这两个IDE版本做了适配。在安装之前我强烈建议你先确认一下自己的RAD Studio版本。打开Delphi菜单Help - About看一下版本号到底是12.0还是12.1还是12.3。为什么这个很重要因为不同小版本的IDE在编译器的底层RTL运行时库上会有细微差异虽然绝大多数控件包可以跨小版本使用但遇到一些跟编译器版本强绑定的组件比如调试器扩展、代码补全插件、带设计时编辑器的那种控件一个小版本不匹配就可能导致IDE里看不到控件。DISQLite3在设计上是比较温和的它不碰IDE的底层扩展只提供VCL/FMX组件和设计时注册接口所以基本上只要大版本对得上就能正常使用。但如果你是从网上某个渠道弄来的安装包安装前先检查一下包内文件命名一般会有Win32、Win64、Android、iOS等子目录分别对应不同平台。2.2 安装步骤详解别急着点Install很多控件包装不上的原因不是控件本身有问题而是安装姿势不对。我分享一下我自己的安装流程基本适用于DISQLite3 v5.48.3以及绝大多数的Delphi组件包。第一步把下载的压缩包解压到一个路径里没有中文和空格的目录比如D:\Components\DISQLite3。这是个老生常谈但永远有人踩坑的点Delphi的IDE在很多环节对中文路径的支持都不好。对了也不建议放到C:\Program Files下因为Windows的用户账户控制UAC机制IDE以管理员身份运行的时候还好如果不是管理员身份访问Program Files下的文件可能会被拦截导致编译报错找不到文件。第二步打开Delphi选择File - Open Project定位到控件包目录找一个后缀为dproj的文件。这个文件在旧版本里是dpkDelphi 2009之后慢慢都改成了dproj。注意一个组件包通常包含好几个工程文件分别对应设计时包和运行时包。比如DISQLite3可能有DISQLite3_R.dpk和DISQLite3_D.dpk这种命名方式R结尾的是运行时包D结尾的是设计时包。安装顺序有讲究先编译安装运行时包再编译安装设计时包。第三步右键工程管理器里的目标工程选择Build。如果顺利会在Messages窗口看到编译成功。然后右键这个工程选择Install。设计时包安装成功之后IDE会弹出一个提示框告诉你组件被注册到了哪个组件面板的哪个页签下。对于DISQLite3来说注册成功后你在组件面板里找以DISQLite开头的组件就能看到。这里要特别提醒一个细节从Delphi 10.3 Rio开始IDE默认是64位和32位编译器并存。如果你的目标平台是Win64那么你在编译安装控件包的时候一定要在工程管理器里把目标平台切换到Win64再Build一次否则你在64位工程里根本找不到这个控件。32位安装只在32位Windows应用程序中生效。很多人在这一步翻车问我为什么控件装上后64位程序用不了原因就是这个。2.3 常见安装报错与排查方法安装控件包常见的报错无非这几类第一个F1026 File not found: System.SysUtils.dcu。这种报错看起来像系统文件缺失其实是IDE的库路径Library Path没有配置好。出现这个报错多半是因为你安装的时候选错了平台或者IDE的Toolchain没有切换到对应的平台。解决办法是先检查Project Manager里当前激活的平台再确认Tools - Options - Environment Options - Delphi Options - Library里是否包含了Delphi自带的RTL路径。第二个E2202 Required package xxx not found。这个报错的意思是编译器需要一个前置的包但找不到。DISQLite3的依赖不算多一般不会出这个问题。真遇到了检查一下是不是少了某个运行库版本或者因为IDE版本太旧导致包编译版本失效这时只能换个和IDE版本匹配的组件包版本。第三个设计时包安装成功但组件面板里找不到组件。遇到这种情况不要急着重启IDE先在搜索框里输入组件的名字关键词比如输入DISQLite3的前几个字母看能不能在组件面板的搜索栏里搜到。有时候组件被注册到某个特定页签下藏在折叠面板里肉眼一扫不容易发现搜索一下是最快的。3. 快速上手拖一个控件连一个数据库跑通第一条Select查询3.1 组件布局与基础属性配置在Delphi里新建一个VCL Application工程或者FireMonkey Application工程然后从组件面板找到DISQLite3相关的组件。常见的有TDISQLite3Database、TDISQLite3DataSet、TDISQLite3UniDirDataSet这几个核心组件。如果你以前用过ADO组件会发现它的用法和你熟悉的TADOConnection加TADOQuery那一套非常像学习成本很低。我以最基础的用法为例。往窗体上放一个TDISQLite3Database把它改名为dbMain。这个组件负责管理数据库连接等效于ADO里的TADOConnection。再放一个TDISQLite3DataSet改名为qryMain。这个相当于TADOQuery负责执行SQL语句并返回结果集。在对象检查器中TDISQLite3Database有一个Database属性双击它打开数据库文件选择对话框。DISQLite3支持两种模式一种是指定一个已经存在的SQLite数据库文件一种是不存在的话在打开连接时自动创建。这个自动创建的特性非常实用尤其适合做单机软件——用户第一次运行程序时你不需要手工去初始化一个空的数据库文件只要设置好连接串程序跑起来数据库自动就生成了。接下来是Connected属性。注意在IDE的设计阶段就把Connected设为True虽然可以直接在设计时看到数据表内容方便调试但有个隐患如果数据库文件路径是相对路径设计时和运行时的工作目录不同会导致运行时连接失败而IDE里还开着这个连接。所以我的习惯是设计时把Connected设成False在Form的OnCreate事件里通过代码打开连接。代码是这样的procedure TForm1.FormCreate(Sender: TObject); var dbPath: string; begin // 获取程序目录下的data.db文件如果不存在会自动创建 dbPath : IncludeTrailingPathDelimiter(ExtractFilePath(ParamStr(0))) data.db; dbMain.Database : dbPath; dbMain.Open; end;这一步做完数据库连接就建好了。接下来就是建表操作。3.2 建表与增删改查DISQLite3和标准SQLite的兼容性DISQLite3对SQLite的SQL语法支持得相当完整标准SQLite的建表、插入、查询语句基本可以直接使用。你可以直接在TDISQLite3DataSet的SQL属性里写SQL语句然后调用ExecSQL执行不返回结果集的语句或者调用Open执行查询。建表代码示例qryMain.SQL.Text : CREATE TABLE IF NOT EXISTS inventory ( id INTEGER PRIMARY KEY AUTOINCREMENT, item_code TEXT NOT NULL, item_name TEXT, quantity INTEGER DEFAULT 0, remark TEXT, created_time DATETIME DEFAULT CURRENT_TIMESTAMP ); qryMain.ExecSQL;写入数据qryMain.SQL.Text : INSERT INTO inventory (item_code, item_name, quantity, remark) VALUES (:item_code, :item_name, :quantity, :remark); qryMain.ParamByName(item_code).AsString : A001; qryMain.ParamByName(item_name).AsString : 测试物料; qryMain.ParamByName(quantity).AsInteger : 10; qryMain.ParamByName(remark).AsString : 这是备注; qryMain.ExecSQL;注意参数绑定的用法。和ADO不同DISQLite3的参数占位符是标准的冒号加参数名而且推荐尽量用参数不要拼字符串。拼字符串最大的风险是SQL注入在单机软件里倒不至于被外人攻击但特殊字符比如英文单引号会把SQL语句搞坏导致莫名其妙的执行失败。这个我踩过无数次坑了凡是用户输入的内容一律走参数。查询数据同样简单qryMain.SQL.Text : SELECT id, item_code, item_name, quantity, remark FROM inventory ORDER BY created_time DESC; qryMain.Open; while not qryMain.Eof do begin Memo1.Lines.Add( qryMain.FieldByName(item_code).AsString | qryMain.FieldByName(item_name).AsString | IntToStr(qryMain.FieldByName(quantity).AsInteger) ); qryMain.Next; end;TDISQLite3DataSet继承自TDataSet所以它天然支持DataSource的关联、DBGrid的绑定也可以使用TDataSet的所有导航方法First、Last、Next、Prior、Locate、Lookup等。这意味着你在Delphi里学的所有DataSet操作知识都能直接迁移过来不用额外学习新的数据访问模式。3.3 一个容易被忽略的设计数据集缓存的用法TDISQLite3DataSet默认是会缓存结果的这一点和SQLite官方驱动那种游标实时读取的模型不一样。这里有个性能上的取舍。如果SELECT语句查出来的数据量特别大比如几百万行默认的缓存方式会把数据全部装载到内存里内存占用就上去了。但换来的是随机访问的速度极快Locate、Lookup这些操作都是在内存里跑比反复查数据库快得多。如果你的数据量在几十万行以内我建议就用默认缓存模式省心。如果数据量真的到了百万级以上要处理大数据集流式读取可以改用TDISQLite3UniDirDataSet组件它是单向只读数据集不缓存优点是内存占用极小缺点是不能随意前后导航只能往一个方向走。实际项目中这个选择很关键。我见过有人用TDISQLite3DataSet去加载一张一百多万行的流水表内存直接涨了好几百兆程序卡得没法看。换成TDISQLite3UniDirDataSet之后内存占用骤降虽然不能随便跳转但配合SQL的分页查询一样很好用。说白了用什么取决于你的场景没有银弹。4. 高级特性与实战细节Delphi 12 Athens下的性能优化、加密与跨平台4.1 事务的使用写数据不再慢吞吞如果你用DISQLite3做批量写入比如从Excel导入几千条数据或者从网络批量接收数据写入本地库你一定会遇到性能问题。我打个比方SQLite默认是每执行一条写操作就把数据从内存写入磁盘并做一次日志记录相当于你每写完一个字就要把整页纸重新抄一遍存档。几千条下来慢到怀疑人生。解决办法就是事务。把一批写操作包在一个事务里让SQLite攒够了再一次落盘磁盘写入次数大幅度减少性能提升是几何级别的。dbMain.Execute(BEGIN TRANSACTION); try for i : 0 to 999 do begin qryMain.SQL.Text : INSERT INTO inventory (item_code, item_name, quantity) VALUES (:item_code, :item_name, :quantity); qryMain.ParamByName(item_code).AsString : Format(A%04d, [i]); qryMain.ParamByName(item_name).AsString : Format(物料%d, [i]); qryMain.ParamByName(quantity).AsInteger : Random(100); qryMain.ExecSQL; end; dbMain.Execute(COMMIT); except dbMain.Execute(ROLLBACK); raise; end;这段代码是把一千条记录以事务方式写进去。你可能觉得1000条不多但不用事务和用事务时间可能差出十倍。我的实测经验是在普通SSD上不使用事务的批量插入在几千条之后速度已经明显开始拉胯加上事务之后几万条也就是眨眼的事。注意异常处理。事务开启之后只要抛出异常一定要执行ROLLBACK否则连接会一直停留在事务状态后续的写操作无法提交成功。这是整个事务流程里最容易漏掉的部分。4.2 加密功能SQLite数据库也能上锁DISQLite3一个很能打的功能是数据库级加密。SQLite官方开源版是不带加密的而DISQLite3内置了AES加密算法可以在创建数据库的时候直接加密。加密之后别人用任何SQLite工具去打开你的数据库文件都会被拒绝根本看不到内容。使用方式很简单在打开数据库之前设置dbMain.EncryptionKey属性dbMain.EncryptionKey : MySecretKey123; dbMain.Database : encrypted.db; dbMain.Open;如果你的数据库是从未加密状态改成加密状态需要在打开旧库之后执行ALTER DATABASE ENCRYPT之类的语句不同版本的DISQLite3语句略有差异具体参见官方文档。一旦设置了密钥后续每次打开这个数据库都必须提供同样的密钥密钥丢了就只能跪着哭了没有任何后门可走。这个功能在做桌面应用交付的时候特别有用。比如给客户做一个小工具数据库里存了客户的业务数据如果数据库没有加密客户随便找个SQLite浏览器就能把数据导出来看没有任何保密性可言。开启了加密至少数据在静止状态下是安全的。4.3 FireMonkey下的跨平台注意事项Delphi 12 Athens对FireMonkey的支持已经非常成熟DISQLite3同样支持在FireMonkey工程里使用而且它支持的平台挺全面Windows、macOS、iOS、Android都有对应的编译目标。这意味着你可以在桌面端写一套业务逻辑然后直接编译到Android平板上跑代码基本不用改动。这正是我之前做PDA盘点程序时的核心工作流。在Windows上开发调试最后部署到Android手持终端。当时用的就是DISQLite3。需要注意几个点。第一数据库文件的路径在移动端上不一致。Windows上可以放到程序目录但Android上程序目录是只读的你需要把数据库放到应用的数据目录里。在FireMonkey里获取这个路径uses System.IOUtils, System.SysUtils; var dbPath: string; begin dbPath : TPath.Combine(TPath.GetDocumentsPath, mydata.db); dbMain.Database : dbPath; dbMain.Open; end;Android的GetDocumentsPath指向的就是应用私有的数据目录不需要额外权限也可以正常读写。第二移动端的SQLite版本和桌面端可能有一些细微差异。SQLite在不断演进DISQLite3也会同步更新SQLite的版本内核。但如果你在Windows上用了一个新的SQLite特性在Android端却报语法错误原因多半是两边的SQLite版本不同或者编译目标时选的SQLite版本不同。解决方法是尽量在需要跨平台时用最基础的SQL语法别用太新的功能。第三PDA设备都是扫码枪一体的。我之前做的一个场景是PDA扫描到条码后程序解析条码然后去本地SQLite数据库里查询物料信息再把查到的数据展示出来。整个过程不依赖网络完全离线。扫描枪在FireMonkey下的输入方式是一个虚拟的键盘输入设备扫码枪扫一下本质上就是快速地往焦点控件里输入一串字符并回车。你只需要在Edit的OnKeyDown里拦截回车键就能拿到完整的条码字符串然后去数据库里执行查询。这个场景下DISQLite3的轻量和稳定非常重要因为设备性能有限数据库连接如果太重扫码查询就会卡顿体验极差。4.4 字符串处理与MD5计算的联动再顺带说一个和数据库查询紧密相关的小技巧。在写业务逻辑时我经常需要对数据做MD5计算比如给每个记录生成一个唯一哈希值用来做数据同步时的版本对比。过去的Delphi版本里计算MD5需要自己写或者引用第三方单元。但Delphi 10.4之后RTL自带System.Hash单元用起来非常方便uses System.Hash; function GetMD5(const S: string): string; begin Result : THashMD5.GetHashString(S); end;我在存储一些敏感信息比如设备序列号、客户编码时习惯在表中加一个hash_code字段插入记录时自动计算并存储。后续做增量同步时只要比较客户端和服务端的hash_code是否一致就能快速判断这条记录有没有被修改过。这个做法在离线缓存与服务器同步的场景里非常常见搭配DISQLite3使用更是顺手。至于字符串处理Delphi里的TStringHelper、Format、Trim、StringReplace这些基础函数在写SQL参数和SQL拼接时都会频繁用到。特别是从扫码枪拿到条码后条码往往有前后空格、换行符合在里面直接拿去做数据库查询会什么都查不到。处理方式也很简单var barcode: string; begin barcode : Trim(edtBarcode.Text); // 去掉首尾空白 barcode : StringReplace(barcode, #13, , [rfReplaceAll]); barcode : StringReplace(barcode, #10, , [rfReplaceAll]); end;别小看这几行代码。扫码枪扫码之后后缀的换行符就是那个经典的扫出来的结果带着回车问题。这一点在FireMonkey的Android端尤其明显不清理的话你还以为是数据库查询逻辑有问题折腾半天结果只是数据里多了个换行。5. 实战案例用DISQLite3做一个带离线缓存的库存查询工具5.1 需求梳理与表结构设计下面我完整走一遍一个实际案例帮助你把前面说的方法串起来。这个案例是一个简化版的库存查询工具运行在Windows桌面端支持从Excel导入库存数据、离线查询、修改库存数量。表结构设计我一开始就定了三张表inventory库存主表、category分类表、sync_log同步日志表。库存主表字段如下CREATE TABLE IF NOT EXISTS category ( id INTEGER PRIMARY KEY AUTOINCREMENT, category_name TEXT NOT NULL ); CREATE TABLE IF NOT EXISTS inventory ( id INTEGER PRIMARY KEY AUTOINCREMENT, item_code TEXT NOT NULL UNIQUE, item_name TEXT NOT NULL, category_id INTEGER, quantity INTEGER DEFAULT 0, price REAL DEFAULT 0, last_updated TEXT, FOREIGN KEY (category_id) REFERENCES category(id) ); CREATE TABLE IF NOT EXISTS sync_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, sync_time TEXT DEFAULT CURRENT_TIMESTAMP, sync_count INTEGER DEFAULT 0, sync_result TEXT );5.2 从Excel导入数据到SQLiteExcel导入这个需求很常见。Delphi里读取Excel有很多方式有的人用TADOQuery直接连Excel有的人用OLE自动化。我不在这里展开假设你已经能拿到Excel中的数据接下来重点是把数据写入DISQLite3库。导入的逻辑我一般这样设计逐行读取Excel数据先按item_code去查inventory表里是否已存在这条记录存在就更新不存在就插入。这个逻辑用SQL写就是一条INSERT OR REPLACE或INSERT ... ON CONFLICT DO UPDATE但为了数据的安全性我倾向于代码里先查一次再决定更新还是插入。下面的代码演示了导入逻辑的骨架procedure TForm1.ImportFromExcel; var i: Integer; itemCode, itemName: string; quantity: Integer; begin dbMain.Execute(BEGIN TRANSACTION); try for i : 0 to 99 do // 假设Excel里有100行数据 begin itemCode : EXCEL_ IntToStr(i); itemName : Excel物料 IntToStr(i); quantity : i * 10; // 查询是否已存在 qryMain.SQL.Text : SELECT COUNT(*) AS cnt FROM inventory WHERE item_code :code; qryMain.ParamByName(code).AsString : itemCode; qryMain.Open; if qryMain.FieldByName(cnt).AsInteger 0 then begin qryMain.Close; qryMain.SQL.Text : UPDATE inventory SET item_name :name, quantity :qty WHERE item_code :code; qryMain.ParamByName(name).AsString : itemName; qryMain.ParamByName(qty).AsInteger : quantity; qryMain.ParamByName(code).AsString : itemCode; qryMain.ExecSQL; end else begin qryMain.Close; qryMain.SQL.Text : INSERT INTO inventory (item_code, item_name, quantity) VALUES (:code, :name, :qty); qryMain.ParamByName(code).AsString : itemCode; qryMain.ParamByName(name).AsString : itemName; qryMain.ParamByName(qty).AsInteger : quantity; qryMain.ExecSQL; end; end; dbMain.Execute(COMMIT); // 写同步日志 qryMain.SQL.Text : INSERT INTO sync_log (sync_count, sync_result) VALUES (:cnt, :result); qryMain.ParamByName(cnt).AsInteger : 100; qryMain.ParamByName(result).AsString : SUCCESS; qryMain.ExecSQL; except dbMain.Execute(ROLLBACK); raise; end; end;5.3 用Locate提升小数据集的查询速度在UI层面当用户在查询框输入item_code时我们希望即时响应。如果inventory表规模不大几万行以内并且已经用TDISQLite3DataSet加载到内存里那么用Locate来做搜索是最快的因为它完全在内存中执行不需要和数据库再做一次交互。代码逻辑大致是这样procedure TForm1.edtSearchChange(Sender: TObject); begin if Trim(edtSearch.Text) then qryMain.Filtered : False else begin qryMain.Filtered : False; qryMain.Filter : item_code LIKE % edtSearch.Text %; qryMain.Filtered : True; end; end;这里我用了Filter而不是Locate。Filter适合模糊匹配Locate适合精确匹配。实际场景里用户往往只记得物料编码的一部分模糊匹配更友好。但Filter如果配合大数据集会比较慢所以我前面说TDISQLite3DataSet的缓存模式只适合中等数据量场景就是基于这样的考虑。5.4 与远程服务器同步时的数据一致性最后说一下离线数据的同步问题。本地SQLite通常不是终点很多程序采集完数据之后需要上传到服务器。同步要考虑数据一致性——本地改了哪些记录服务器又改了哪些最简单的方案就是前面提到的hash_code比对。流程是这样的本地的每条业务记录都有一个last_updated时间戳和hash_code字段。每次本地修改数据时更新last_updated为当前时间从新计算hash_code。同步时服务器返回最新的数据哈希列表客户端逐一比对。不一致的记录以服务器为准覆盖或者以本地为准上传规则取决于业务需求。同步完毕后更新本地sync_log表记录执行结果。DISQLite3对事务的良好支持让这个同步过程非常可靠先在一个事务里读取需要同步的数据组装成JSON发送给服务器服务器确认接收后再在一个事务里更新本地同步状态。如果中途网络断了本地事务回滚不会出现半同步的脏状态。说到JSONDelphi 12自带的System.JSON处理这个场景是够用的。从SQLite读出结果集序列化为JSON数组只需要几行代码uses System.JSON; function InventoryToJson: TJSONArray; var obj: TJSONObject; begin Result : TJSONArray.Create; qryMain.SQL.Text : SELECT item_code, item_name, quantity, price FROM inventory; qryMain.Open; while not qryMain.Eof do begin obj : TJSONObject.Create; obj.AddPair(item_code, qryMain.FieldByName(item_code).AsString); obj.AddPair(item_name, qryMain.FieldByName(item_name).AsString); obj.AddPair(quantity, TJSONNumber.Create(qryMain.FieldByName(quantity).AsInteger)); obj.AddPair(price, TJSONNumber.Create(qryMain.FieldByName(price).AsFloat)); Result.AddElement(obj); qryMain.Next; end; end;Delphi的JSON序列化性能说不上顶级但对于离线采集、定时上报这种频率不高的场景完全够用。6. 常见问题与排查技巧实录6.1 控件版本冲突导致每次进IDE都丢失控件你的热词里有一条特别典型的求助delphi 控件版本问题 导致 每次进入ide都丢失控件需要重新放置保存后还是那样。这个问题我见过的次数非常多在DISQLite3身上也有可能出现。先解释一下为什么会这样。Delphi窗体文件.dfm在保存时会记录每个组件所属的类名和单元名。当你打开含有某控件的窗体时IDE会尝试加载对应的设计时包。如果IDE找不到这个控件比如设计时包没有安装或者安装的版本和.dfm里记录的类名不一致IDE就会报错并且把这个控件从窗体上隐藏掉。如果保存了窗体那这个控件就真的从.dfm里被移除了下次打开再也找不回来。所以遇到这个问题排查思路是确认设计时包是否真的安装成功了。菜单Component - Install Packages检查列表里有没有对应项。确认安装的控件版本和当前IDE的版本匹配。Delphi 11的包安装到Delphi 12里因为编译器生成的.dcu文件不兼容IDE会在加载时静默失败那自然就表现为控件时有时无。检查.dfm文件里的类名是否和实际控件一致。如果你之前装了某控件后来又卸载了但窗体里的引用还在那窗体一打开就会报类名不存在之后IDE可能就自作主张把不认识的对象去掉了。我的建议是不要依赖IDE在打开窗体时自动加载缺失的控件来恢复现场。正确做法是装好控件包之后再把窗体里的旧引用手动更新一遍或者直接改.dfm源文件里的类名替换成新控件的类名。再狠一点把窗体文件在记事本里打开手动删除不属于当前环境的对象定义。这个方法比较粗暴但有效。6.2 数据库文件被占用导致无法打开在开发调试阶段DISQLite3的数据库文件经常被IDE里的设计时连接占用。你运行程序时会看到数据库文件被锁定或者提示database is locked原因往往就是你在设计时把Connected属性设成了TrueIDE还保持着连接然后运行程序时又开了一个连接去访问同一个文件。SQLite允许多个连接同时读但写操作是排他的。如果你发现编译能通过一运行就报数据库被锁先检查IDE里是否还有连接没关。最简单的做法数据库组件的Connected属性保持False所有的连接打开和关闭都通过代码控制不依赖设计时预览。6.3 Select查询慢的排查思路如果你发现DISQLite3的Select查询很慢先不要急着怪控件对照下面三个方向排查。第一是否缺少索引。这是最常见的原因。如果你的业务经常按item_code查询item_code字段上要不要建索引答案是肯定要建。建索引的SQL是CREATE INDEX idx_inventory_item_code ON inventory(item_code);索引的代价是写入变慢、文件变大但查询速度提升明显。在百万级数据量下有没有索引的差距是数量级的。第二是否在循环里反复打开和关闭数据集。这是一种很常见的编程坏习惯。有人会在while循环里挨个执行查询每次查询都创建一个新的TDISQLite3DataSet用完再释放。这种写法会让SQLite反复执行语句的解析、优化和缓存重建开销巨大。正确做法是循环外写好一次SQL复用同一个数据集只改变参数值。第三是否因为ListView或DBGrid联动触发了重复查询。在UI层有时候你滚动列表时某个事件会反复触发查询实际上数据根本没变。排查方法是在关键查询方法入口打一个OutputDebugString或者写日志看看查询频率是否异常。6.4 Delphi 7等老版本项目升级时的注意事项我在热词里看到了delphi 7搜索说明还有人在维护老项目。如果你正准备把一个Delphi 7的老项目迁移到Delphi 12 Athens同时还想用DISQLite3有几个坑必须先知道。第一老项目里如果用了AnsiString、PChar做字符串直接操作新版本编译大概率会有一堆类型不匹配的报错。因为Delphi 2009之后默认字符串类型是UnicodeString。DISQLite3的组件接口是按新字符串类型设计的所以你的老代码往数据库里写中文时需要确认一下有没有做显式编码转换。第二老项目的第三方控件如果只有Delphi 7版本的包迁移到Delphi 12时多半编译不过。DISQLite3还算良心v5.48.3明确支持11-12 Athens但如果你用的是其他更老的控件建议先做一次全面的依赖盘点看看哪些控件有新版哪些控件已经停止维护。停更的控件要么自己改源码适配要么趁迁移机会一并换掉。硬撑着不换后面每次升级IDE都是一场灾难。第三老项目里可能大量使用了全局变量保存数据库连接状态。这种写法在新IDE和多线程环境下容易出问题。DISQLite3的TDISQLite3DataBase对象本身不是线程安全的如果一个全局数据库连接被多个线程同时访问轻则查询报错重则内存崩溃。多线程场景一定要做到一线程一连接或者用临界区保护访问。6.5 一个小技巧用DISQLite3执行DOS命令的返回值做数据更新热词里还有一个delphi 执行dos命令获取返回值。你会不会觉得这和数据库没关系其实关系挺大的。我在做设备数据采集工具时经常需要用程序去执行一个外部命令比如读取硬件状态、调用设备自带exe导出一个csv文件然后把命令输出解析后写入SQLite。Delphi执行DOS命令并捕获输出用TProcessFireMonkey或者CreateProcessWindows API都行。给个最简单的用TProcess的例子uses System.Diagnostics; function RunCommandAndGetOutput(const ExeName, Params: string): string; var Process: TProcess; Output: TStringList; begin Process : TProcess.Create(nil); Output : TStringList.Create; try Process.Executable : ExeName; Process.Parameters.Add(Params); Process.Options : [poUsePipes, poWaitOnExit]; Process.Execute; Output.LoadFromStream(Process.Output); Result : Output.Text; finally Output.Free; Process.Free; end; end;拿到命令输出之后再用Split或正则表达式解析字段然后组装SQL插入DISQLite3。整个过程看似绕了一下但实际业务里外部程序输出数据 - 本地数据库落盘是一个非常经典的组合。我在工厂设备数据采集时就是靠这个思路每天定时调用设备管理软件导出一条CSV再启动Delphi程序解析CSV并写入SQLite常年稳定运行。7. 一些实在的总结DISQLite3到底值不值得深入用下去如果你已经看到了这里说明你大概率是真的在考虑用DISQLite3或者在踩坑之后想要一个更稳的方案。那我说几句实在话。DISQLite3不是最惊艳的数据库组件它的API不花哨UI也不炫。但它的核心竞争力非常扎实纯Delphi实现、无DLL依赖、稳定、跨平台、内置加密背后还有一个持续更新的商业公司在维护。对大多数Delphi应用来说这种稳比炫重要得多。我个人在实际操作中的体会是组件选型这件事不要贪多不要追新。找到一个自己熟悉的、能稳定交付的方案比反复换库换组件付出的学习成本要低得多。DISQLite3这个组件只要你把安装、连接、事务、加密、跨平台这五个点吃透应付日常90%的本地数据库场景是没有问题的。可能它不是每篇技术文章里最亮眼的那个但它会是你在项目交付当天晚上敢安心睡觉的那个。最后再分享一个我自己的习惯不管用哪个数据库组件每写一个涉及数据库的操作我都会在关键步骤前后加上日志输出。很多人懒得写日志觉得调试直接用断点就够了。但数据库的问题是数据状态的问题断点看不到数据状态的变化轨迹只有一段完整的日志才能还原整个执行过程。尤其是上了事务、加了加密、做了跨平台之后出了问题靠日志去倒推比靠断点去猜要快得多。这不是DISQLite3特有的建议但配合DISQLite3这种稳定型控件这套工作方式是真的很搭。本文还有配套的精品资源点击获取