简介面向 Delphi 6 至 13.1 开发者的 Devart IBDAC v9.0.0 组件套件专门用于高效连接与操作 InterBase 和 Firebird 数据库解决跨版本数据访问、执行效率及高级特性集成等问题尤其适合需要深度数据库控制能力的中高级桌面、工具软件及企业应用开发者新版已针对 Delphi 最新版本 Florence 进行了专门优化。压缩包共 2000 个文件以 Delphi 工程文件dpk、dproj、Pascal 源码pas、头文件hpp及配置脚本cfg为主并包含构建批处理、示例工程与项目组文件这些不同后缀分别对应组件库、项目配置、资源描述和辅助构建脚本整包约 17.01MB目录结构清晰便于快速定位组件或参考案例。目前已有 63 人学习下载对于需要快速上手 IBDAC 或深入理解其内部机制的开发者具有直接参考价值。内附完整源代码可查看组件实现细节并自行扩展支持本地 API 调用加速交互、细粒度事务控制保障一致性、异步操作避免界面阻塞、RESTful 接口便于 Web 暴露数据同时覆盖 InterBase 存储过程、触发器及 Firebird 高级数据类型处理配合详细文档和示例代码能显著降低集成门槛并提升数据库应用的开发效率。1. 一句话说清 IBDAC v9.0.0Delphi 13.1 接 Firebird/InterBase 最省心的控件选型Delphi 13.1 下做 InterBase 或 Firebird 数据访问绕不开「控件选型」这一关。IBDACInterBase and Firebird Data Access Components是 Devart 出的一套商业数据访问组件v9.0.0 这个版本覆盖 Delphi 6 到 13 的完整版本线等于把老项目迁移和新项目起步两件事都铺平了。这篇文章要解决的不是「它好不好用」这种空泛问题而是三个更具体的诉求它比 IDE 自带的 IBX 和 FireDAC 强在哪、最小连接代码怎么写、以及哪些参数和坑决定你上线后是顺跑还是翻车。适合正在维护老 Delphi 应用、或准备在 13.1 上从零接 Firebird 的开发者。2. 为什么不用 IBX 和 FireDACIBDAC 的架构差异与选型理由先说结论如果你的目标数据库明确就是 InterBase/FirebirdIBDAC 是三者里最「懂行」的如果项目可能换库FireDAC 才值得考虑如果是老 IBX 工程想低成本续命IBDAC 几乎是唯一平滑路径。2.1 IBDAC 与 IBX 同源不同命Direct 模式干掉 fbclient.dll 依赖Delphi 自带的 IBXInterBase Express本来是 Borland 随 IDE 发布的组件集单元名沿用到现在IBDatabase、IBQuery、IBTransaction 这套命名 IBDAC 完全兼容。这意味着从一个老 IBX 项目切到 IBDAC大部分情况下只要换 uses 里的单元路径、再补一两个属性赋值代码不用大改。这是 IBDAC 的第一个隐性价值迁移成本低到可以按「周末加班一天」来估。但 IBX 有个老毛病它必须通过客户端库访问数据库。连 InterBase 要 gds32.dll连 Firebird 要有 fbclient.dll而且 32 位/64 位版本不能混用客户端库版本和服务器版本不一致还会触发各种莫名其妙的协议错误。IBDAC 的解决方案是提供两种连接模式Standard 模式仍然走 fbclient.dll和 IBX 一致Direct 模式则内置了协议实现不依赖任何外部 DLL直接通过 TCP 端口 3050 和服务器对话。Direct 模式的实际价值在部署环节最大。我给客户做交付时最怕的就是现场机器上 DLL 版本不对、被杀毒软件隔离、或者用户自己换了个 64 位客户端库导致程序起不来。用 Direct 模式exe 拷过去就能跑数据库连接串里写服务器地址和端口就行。代价是 Direct 模式对 Firebird 3 以上版本的新认证协议支持不总是及时这个具体坑在第 5 章展开。2.2 FastKeys 与事务隔离两个我用过之后回不去的特性IBX 每次执行一条 SQL 前都要向服务器请求字段列表、参数信息等元数据哪怕同一条 SQL 执行一百遍这一百遍的元数据往返一次都省不掉。IBDAC 的 FastKeys 机制会把 SQL 文本对应的元数据缓存到本地第二次执行时直接命中缓存。老项目里那种循环里反复执行同一条 UPDATE 的场景换到 IBDAC 后体感速度变化非常明显不是玄学是省掉了实实在在的网络往返。事务方面IBDAC 的 TIBTransaction 隔离级别可选范围比 IBX 更完整。我在生产环境最常用的是 ibReadCommitted读到的都是已提交数据不会出现脏读同时锁粒度比 ibConsistency 小得多。需要做批量报表扫描时再临时切到 ibSnapshot让事务看到启动时刻的一致快照避免长查询被其他会话的提交干扰。隔离级别不是越高越好关键是控制在「不脏读」和「不锁死」之间这个平衡点 IBDAC 给足了选项。2.3 选型对比IBX、FireDAC、IBDAC 三张表看清边界对比项IBXDelphi 自带FireDACEMBA 出品IBDACDevart目标数据库InterBase 为主Firebird 兼容一般多数据库统一抽象只做 InterBase/Firebird做得深客户端库依赖必须 gds32.dll / fbclient.dll需要对应驱动 DLLStandard 模式需要Direct 模式不需要IBX 代码兼容性本身就是 IBX不兼容API 差异大完全兼容单元名一致元数据缓存无有但按多库通用逻辑实现FastKeys针对 Firebird/InterBase 特性优化部署体积小中Direct 模式下最小许可成本免费随 IDE 版本授权商业授权按开发者计费单看这张表FireDAC 似乎功能更多但多数据库抽象带来的代价是针对 InterBase 的某些专属特性支持滞后比如 Firebird 的数组字段、PSQL 块调试这类偏门能力。项目确定不换库时IBDAC 的「专」比 FireDAC 的「全」更值钱。我的建议是老 IBX 项目直接换 IBDAC全新项目且预算允许也选 IBDAC只有「今天 Firebird 明天可能换 Oracle」这种明确需求才考虑 FireDAC。3. 在 Delphi 13.1 里装好 IBDAC版本矩阵、安装路径与 IDE 集成安装这一步劝退了不少新手。IBDAC 安装本身不难难在装完之后 IDE 里看不到组件、或者编译时提示找不到单元。这一章把版本匹配和安装路径讲清楚照着做基本一次过。3.1 先读版本矩阵v9.0.0 对 Delphi 6-13 的支持边界标题里的「v9.0.0 for Delphi 6-13」说的是这个版本的分发包同时携带了从 Delphi 6 到 Delphi 13 的运行时包和设计时包。安装程序会根据当前 IDE 版本自动选择对应的 .bpl 和 .dcp 文件理论上不需要手动指定。但有一个常见认知偏差要纠正包覆盖范围不等于「装一次所有版本都能用」。如果你的机器上同时装了 Delphi 12 和 Delphi 13.1安装程序只会给当前激活的 IDE 注册组件另一个 IDE 里看不到 Devart 组件页是正常的需要单独为它再跑一次安装或者手动注册包。从 Delphi 12 升级到 Delphi 13.1 的项目尤其要注意IDE 主版本变了设计时包必须重新安装否则就算你在旧版本里把一切调好了新 IDE 打开工程依然会报「Cannot find package Devart.IBDAC…」。升级后不要直接点开旧工程先重装控件再开工程。3.2 安装三步走IDE 缓存、组件页与包注册常见做法是分三步完成安装环境准备关闭 Delphi以管理员身份运行安装程序选择当前 IDE 版本对应的组件。安装界面里会有已检测到的 Delphi 版本列表勾选你实际在用的那个。启动 Delphi打开 Component Install Packages确认 Devart InterBase and Firebird Data Access Components 出现在列表里。如果没有手动点击 Add 按钮到安装目录的 Bin 文件夹下选对应的 .bpl 文件。打开 Tools Options Environment Variables检查 Library 路径里是否包含 IBDAC 的 Source 目录。新版安装程序一般会自动加但老版本或者手动安装的场合经常漏掉这一项导致编译时报「Unit IBDatabase not found」。安装完打开组件面板往下翻到「Devart InterBase and Firebird Data Access Components」这一页。这里有个容易误判的点如果页面上只有 TIBDatabase、TIBQuery 等若干组件而没有看到服务类组件可能是安装时勾选了精简安装项。服务组件在 IBServices.pas 单元里稍后第 6 章会用它的备份功能做验证建议安装时选完整组件集。3.3 64 位项目与 DLL 放置Win64 平台下的经典翻车现场Delphi 13.1 默认支持 Win32 和 Win64 两个编译目标。Win32 编译时Standard 模式的 fbclient.dll 通常放在 exe 同目录就能加载但切到 Win64 后很多人直接把 32 位的 fbclient.dll 拷到新目录运行时报「Unable to load fbclient.dll」。原因很简单64 位进程加载不了 32 位 DLL反之亦然。我一般会在每个项目的 Release 输出目录下建一个3rd\fbclient子目录分别维护 x86 和 x64 两个版本的客户端库然后用初始化代码按当前平台动态指定 DLL 路径。如果不是特别需要 Standard 模式部署时可以优先考虑 Direct 模式直接从源头避开 DLL 版本匹配问题——这也是上一章为什么先讲 Direct 模式的意义。提示判断当前进程位数可以用TOSVersion.Architecture也可以在Initialize事件里按Win32/Win64编译指令做条件编译。4. 跑通第一条 IBDAC 查询从连接串到参数化查询的完整代码原理讲再多不动手跑通一条查询都等于零。这一章给最小可用代码建连接、开事务、参数查询、处理结果集四件事一次讲完。4.1 最小连接串Server、Database、CharacterSet 三个字段必须写对IBDAC 的连接对象是TIBDatabase它的DatabaseName属性可以直接写连接串。最精简的 Firebird 连接串长这样DB.DatabaseName : Server127.0.0.1;Port3050; DatabaseC:\DATA\SAMPLES.FDB; UserSYSDBA;Passwordmasterkey; CharacterSetUTF8;ExtendedMetadataTrue;Server写主机名或 IPPort默认 3050除非服务器改过端口否则不用写。Database是服务器视角的数据库文件路径不是客户机路径跨机器部署时最容易在这里翻车。CharacterSetUTF8是必选项不写的话客户端默认以 NONE 字符集连接中文读写大概率变问号。ExtendedMetadataTrue让控件保留更完整的字段元数据比如 NUMERIC/DECIMAL 的精度信息建议一直开着代价只是多占一点内存。写完连接串后手动设DB.Connected : True可以立刻验证服务器地址、端口和账号密码是否正确。连不上时先检查 Firebird 服务有没有启动、3050 端口是否被防火墙拦这两条比任何代码排查都好使。4.2 第一条查询事务、参数、结果集的标准骨架IBDAC 里连接和事务是两个独立对象必须先绑定再使用uses IBDatabase, IBQuery, IBTransaction; procedure TForm1.OpenCustomers; var DB: TIBDatabase; TR: TIBTransaction; Q: TIBQuery; begin DB : TIBDatabase.Create(nil); try DB.DatabaseName : Server127.0.0.1;Port3050; DatabaseC:\DATA\SAMPLES.FDB; UserSYSDBA;Passwordmasterkey; CharacterSetUTF8;ExtendedMetadataTrue; TR : TIBTransaction.Create(nil); try TR.DefaultDatabase : DB; // 先绑事务再连数据库 TR.IsolationLevel : ibReadCommitted; DB.Transaction : TR; // 连接上的默认事务 DB.Connected : True; Q : TIBQuery.Create(nil); try Q.Database : DB; Q.Transaction : TR; Q.SQL.Text : SELECT ID, NAME, CREATED_AT FROM CUSTOMERS WHERE ID :MIN_ID ORDER BY ID; Q.ParamByName(MIN_ID).AsInteger : 100; Q.Open; while not Q.EOF do begin // 这里读字段例如 Q.FieldByName(NAME).AsString Q.Next; end; finally Q.Free; end; TR.Commit; finally TR.Free; end; finally DB.Free; end; end;这段代码有三个关键顺序不能乱先TR.DefaultDatabase : DB再DB.Connected : True否则事务不知道挂到哪个连接上运行时报「No default database assigned to transaction」查询必须用Q.Open而不是Q.ExecSQL前者返回结果集后者只执行不带返回集的语句循环读完结果后要TR.Commit提交事务不提交的话连接会一直持有一个活动事务后面会演变成第 5 章说的锁库问题。Q.ParamByName(MIN_ID).AsInteger : 100是参数化查询的标准写法。参数名前要带冒号但赋值时不用写冒号。参数化不只是防注入更重要的价值是让 Firebird 能复用执行计划配合 FastKeys 缓存同一查询第二次执行时快得多。4.3 写入操作与事务边界Commit 和 CommitRetaining 别再混用插入和更新的代码骨架和查询类似区别只在 SQL 和调用方法Q.SQL.Text : UPDATE CUSTOMERS SET NAME :NAME WHERE ID :ID; Q.ParamByName(NAME).AsString : 张三; Q.ParamByName(ID).AsInteger : 100; Q.ExecSQL; TR.CommitRetaining; // 提交但保留事务和结果集CommitRetaining提交当前事务的数据变更但事务对象仍然处于活动状态游标也不会失效。这在小步批量处理时很顺手每更新一批数据提交一次既不会让事务无限膨胀又不用重建事务对象。但要注意CommitRetaining在 Firebird 里意味着事务在下一语句开始时自动开启新事务如果逻辑里混用了Commit和CommitRetaining容易出现「我以为提交了其实还有隐藏活动事务」的情况。我的习惯是一个方法内只用一种提交方式宁可多写几行代码重建事务也不图省事混着用。5. IBDAC 避坑实录五个上线前必须知道的现场问题这一章的内容全部来自实际项目里被人问过的、自己也踩过的重复率最高的问题。每条按「现象 → 原因 → 解决」写方便你遇到时快速对照。5.1 安装完组件面板里没有 Devart 页现象安装程序跑完重启 Delphi 后组件面板找不到 Devart InterBase and Firebird Data Access Components 这一页。原因安装时 IDE 版本勾选错误或者安装程序写入的注册表信息被 IDE 缓存覆盖。Delphi 启动时会缓存组件包列表缓存文件和当前 IDE 版本不匹配时新装的包不会被加载。解决先到 Component Install Packages 里手动 Add定位到安装目录 Bin 下的Devart.IBDAC.design.bpl。如果手动添加后还是看不到关掉 Delphi删除%AppData%\Embarcadero\BDS\下对应版本号的临时缓存目录重新启动 IDE。多数情况下删缓存这招比重装管用。提示中文版 Windows 上的用户目录路径可能是中文用户名删除缓存前先确认 BDS 目录的真实路径别用错了版本号文件夹。5.2 写进去的中文读出来全是问号现象通过 IBDAC 写入 Firebird 的中文数据用数据库工具看是正常的但程序再读出来变成「???」或乱码。原因连接串没有指定CharacterSet客户端默认以 NONE 字符集连接数据库。Firebird 的 NONE 字符集会按字节原样传输应用层和数据库层编码不一致时中文就是问号。这和 Delphi 中文版本没关系纯粹是数据库字符集匹配问题。解决连接串里加CharacterSetUTF8同时在创建数据库时就用 UTF8 字符集。如果库里已经有乱码数据只能先导出再用正确字符集重建库没有后悔药可吃——所以新库建议从建库第一天就把字符集钉死。顺带说一句Firebird 3 以上 UTF8 数据库的默认排序规则是UNICODE_CI_AI大小写不敏感排序在中文场景下表现比老版本好很多值得升级。5.3 程序退出时偶发锁库数据库文件删不掉现象程序正常关闭后再打开同一个数据库提示database is locked或者备份工具提示数据库正在使用。原因最常见的是退出路径里没有显式关闭事务和连接。IBDAC 默认KeepConnection行为会让连接在组件释放前保持打开状态如果某个事务只Rollback没Commit连接就会残留一个活动事务。程序异常终止时服务端的活动连接不会立刻清理。解决在关闭流程里按「先事务、再连接」的顺序显式释放if TR.InTransaction then TR.Rollback; DB.Connected : False; DB.Free;如果你的程序用了连接池还要确认空闲连接有超时回收机制不能只靠进程退出兜底。另外 Firebird 服务端的databases.conf里可以设置ConnectionTimeout让长时间空闲的连接被服务端强制回收这是生产环境防止残留连接占库的保险丝。5.4 Direct 模式连不上 Firebird 3 以上的库现象代码和数据都没问题连接串用 Direct 模式连 Firebird 2.5 好好的换到 Firebird 3 或 4 的服务器上就报your user name and password are not defined哪怕账号密码确认无误。原因Firebird 3 开始默认启用 SRP 认证和 WireCrypt 加密传输老版本直连驱动的认证握手方式和服务端对不上。这不是账号问题是协议版本不匹配。解决两个方向选一个。短期方案是改用 Standard 模式并放置与服务器版本匹配的 fbclient.dll让认证交给官方客户端库处理长期方案是检查 IBDAC 版本是否已更新到支持新版认证的构建。如果必须在 Direct 模式下工作需要在服务端调整firebird.conf的认证插件顺序把Legacy_Auth打开——但这会降低安全性只建议在内网环境这么做。5.5 多线程里共用连接偶发 ISC 错误现象Delphi 多线程业务里多个线程同时用同一个TIBDatabase和TIBQuery执行查询运行一段时间后随机报 ISC 错误码或connection is closed。原因IBDAC 的连接对象不是线程安全的。多个线程共享一个连接对象并发操作等于同时往同一个 Socket 里写数据底层句柄必然打架。这是数据库组件的通用规则一个连接同一时刻只能被一个线程使用。解决每线程单独创建TIBDatabaseTIBTransactionTIBQuery线程结束时显式关闭并释放。如果连接数多就配合下一章的连接池控制上限而不是共享单个连接。记住一个原则线程可以共享「连接池」不能共享「连接实例」。6. 把 IBDAC 用得更顺连接池、数组 DML 与备份验证最后一章讲三个能立刻用上的进阶点也是我上线前必做的三件事。6.1 多线程并发的第一道闸连接池参数IBDAC 的连接池不在TIBQuery上而在连接对象的 Pool 相关属性里。不同小版本属性名略有出入搜索 Pool 关键字就能找到。开启后连接对象关闭时物理连接不真正断开而是归还到池里供下一个使用者复用。多线程场景下我会把池上限设成略大于最大并发线程数避免线程切换时反复建连。池开太大没用开太小线程会排队等待这个参数要根据实际并发量调没有统一最优值。6.2 数组参数批量 DML一次提交替代循环循环里逐条执行 UPDATE 是很费的做法IBDAC 支持数组参数一次调用把整批数据发给服务器Q.SQL.Text : UPDATE INVENTORY SET QTY :QTY WHERE ID :ID; Q.Prepare; Q.Params[0].ArrayLength : ItemCount; Q.Params[1].ArrayLength : ItemCount; for i : 0 to ItemCount - 1 do begin Q.Params[0].AsIntegers[i] : NewQty[i]; Q.Params[1].AsIntegers[i] : IDs[i]; end; Q.ExecSQL;这套数组接口是 IBDAC 在 IBX 基础上扩展的如果 IDE 提示找不到AsIntegers检查 uses 里是否确实引用了 IBDAC 的 IBQuery 单元而不是别的同名单元。批量更新务必放在一个事务里提交速度比逐条提交快一个量级这也是我优化后台批处理任务的首选手段。6.3 上线前最后一步用服务组件验证备份恢复我习惯在交付前用 IBServices 单元里的TIBBackupService做一次在线备份验证。备份能成功说明连接、权限、字符集全链路都没问题备份失败则说明某个环节仍有隐患不适合直接上线。验证完记得把备份文件恢复到一个临时库跑一遍关键查询确认数据和程序预期一致。这些年换下来的血泪经验是控件选型可以靠性能参数说服人但真正决定项目成败的往往是安装路径、字符集和连接生命周期这些细节。把这一章和上一章的坑都过一遍Delphi 13.1 IBDAC Firebird 这套组合就算稳了。希望帮到你。本文还有配套的精品资源点击获取
