简介Unidac 5.3.9 完整资源包专为 Delphi 与 CBuilder 开发者设计用于快速接入 Oracle、MySQL、SQL Server、PostgreSQL、SQLite 等多种数据库。其直接访问机制相比传统 ADO 或中间层方案能带来更高执行效率和更低内存占用适合各类桌面端、移动端及服务端应用的数据库层开发。资源共 2000 个文件包含 613 个 pas 源码、375 个 dpk 组件包、304 个 cfg 配置以及 84 个 dfm 窗体文件。pas 源码便于二次开发dpk 用于组件安装bmp 图标、res 资源等辅助界面与工程构建整体仅 17.15MB结构紧凑却覆盖完整。包内提供 ReadmeSrc.html、Help 帮助文档、History 版本记录以及 Demos 示例代码可快速掌握连接管理、事务处理、SQL 查询等典型用法Source、Include、Lib 目录则为深入源码或自定义编译提供便利。已有 123 人学习适合需要稳定跨数据库访问能力的项目开发者选用。1. UniDAC 5.3.9一套 Delphi 代码连遍主流数据库的通用数据访问组件如果一个人用 Delphi 写数据库应用几乎早晚会撞上这个问题项目要求从 SQL Server 换到 MySQL或者发布时客户那边只装了 PostgreSQL。改连接串简单但代码里到处是 TQuery 的 SQL 方言、参数类型、自增字段获取方式一换库就遍地报错。UniDAC 5.3.9 就是专门解决这个问题的通用数据访问组件通过一个 TUniConnection 连接不同数据库用 TUniQuery 读写数据SQL 层的差异交给组件屏蔽同时保留必要时写原生 SQL 的通道。它适合维护老 Delphi 项目的人也适合需要在多个数据库之间切换交付方案的团队。这一篇我按实际使用顺序把 5.3.9 的原理、安装、连接配置、参数差异和踩坑记录完整过一遍。2. UniDAC 5.3.9 的取巧之处连接组件怎么替你屏蔽数据库差异UniDAC 的组件模型看上去和传统 BDE 那套很像但内部结构完全不同。用 TUniConnection 做连接载体TUniQuery 做查询载体TUniTable、TUniStoredProc 分别对应简单表操作和存储过程调用。关键在 TUniConnection 的 ProviderName 属性——一个字符串取值范围是 MySQL、Oracle、PostgreSQL、SQL Server、SQLite 等。设置 ProviderName 之后组件内部按名字加载对应 Provider 模块把连接、事务、命令执行全部转发给底层驱动。你的工程不需要同时引用多套数据库原生组件代码里不会出现 xxQuery、yyTable 混在一起的局面。UniDAC 会对每种数据库维护一套元数据类型映射表、SQL 方言集合、参数符号规则、自增字段获取方式。切换 ProviderName 后同一段代码里的数据类型会被重新解释。比如 MySQL 的 TINYINT(1) 在默认映射下读到的是整型而不是 Delphi 的 Boolean想要 Boolean 需要另配字段类型映射。这一点很多人第一次用会意外但理解它是 UniDAC 的底层机制后就明白组件翻译的是类型不是替你做业务判断。5.3.9 是 5.x 系列的一个稳定小版本。日常需要的特性基本都齐了直连模式、宏替换、数组 DML、UniSQL、事务控制。直连模式是 UniDAC 比较吸引人的点——程序使用组件内建的驱动实现不依赖数据库官方客户端软件部署时不用在目标机器安装 Oracle 客户端或 MySQL 客户端把对应动态库放到程序目录就行。注意部分 Provider 的直连模式对某些数据库特性支持有边界实际项目里我一般先用直连模式快速验证碰到连不上再退回客户端库模式改动只是连接属性里的一个开关。2.1 核心组件是 TUniConnectionProviderName 一改驱动全换TUniConnection 在 UniDAC 里的地位相当于传统 BDE 里的 TDatabase。设计期从组件面板拉一个到窗体上右键选择 Edit Connection填写服务器、端口、数据库、用户名、密码点 Connect 测试。连接成功后这些参数会序列化到 DFM 文件里程序启动后会按 DFM 中的信息自动恢复连接状态。运行期也可以完全通过代码赋值适合连接信息来自配置文件、注册表或远程接口的场景。这里有一个容易被忽略的约束修改 ProviderName 前必须先断开连接。如果你在一个已经连接的实例上直接改 ProviderName组件会抛出异常或者更糟——保留当前连接但属性显示为另一个 Provider后续操作行为变得不可预测。我一般会在切换前显式写上 Connected : False再改 ProviderName再重新赋值连接参数。这个习惯能省掉很多莫名其妙的运行时问题。2.2 差异藏在 Provider 内部类型映射、方言生成与直连模式UniDAC 的宏替换机制是处理 SQL 方言差异比较顺手的手段。举例获取当前时间MySQL 用 NOW()SQL Server 用 GETDATE()PostgreSQL 用 CURRENT_TIMESTAMP。与其在每处代码写分支不如在连接上定义一个宏UniConn.Macros.Clear; UniConn.Macros.Add(CurrentTime NOW()); // MySQL 环境 UniConn.Macros.Add(CurrentTime GETDATE()); // SQL Server 环境 // UniConn.Macros.Add(CurrentTime CURRENT_TIMESTAMP); // PostgreSQL 环境定义好宏之后SQL 文本里使用花括号引用它UniQuery.SQL.Text : SELECT {CurrentTime} AS NowTime; UniQuery.Open;执行时组件会把 {CurrentTime} 替换成当前 Provider 对应的方言。这样你的 SQL 文本保持统一数据库差异收敛到连接层。替换是纯文本级的宏里可以放完整的表达式不只是单个函数名。如果你在 SELECT 语句里写了一个包含冒号的字符串常量并且这个常量不该被当作参数那么需要用连续两个冒号转义这是 UniDAC 参数解析的固定规则很多初次使用的人在这里被绊过。类型映射方面UniDAC 的做法是每个 Provider 自带映射表。MySQL 的 VARCHAR 映射为 StringMEDIUMINT 映射为 IntegerPostgreSQL 的 NUMERIC 默认映射为 Extended 或浮点Oracle 的 NUMBER 会根据精度决定是 Integer 还是 Float。你可以在字段编辑器里手动改成更合适的 Delphi 类型但要意识到映射只影响组件返回给你的是什么类型库表里真正存的还是数据库原生的东西。设计时养成查看映射结果的习惯比上线后处理类型转换异常便宜得多。3. 拿到 UniDAC 5.3.9 后IDE 安装、运行时文件与第一个连接3.1 安装三步走源码包编译到组件面板出现UniDAC 的发行包通常包含运行期包和设计期包。拿到源码版后的标准安装路径是先在 IDE 中打开对应版本运行期包后缀一般是 .dpk 或 .dproj编译通过后生成 .bpl 和 .dcp 文件随后打开设计期包执行 Install让组件注册到 IDE 组件面板最后在 Component Palette 里确认出现 UniDAC 页里面有 TUniConnection、TUniQuery、TUniTable、TUniStoredProc 等组件。这里最容易翻车的是选错包文件。不同 IDE 版本对应的包编译目标不同用旧包的现成 bpl 装到新版 IDE 会直接报“无法找到运行时包”或提示版本不匹配。解决办法是回到源码包里找到带当前 IDE 版本宏的包文件重新编译而不是硬装现成的 bpl。装好后如果组件面板里没看到 UniDAC 页检查 IDE 的 Library 路径里是不是同时存在新旧两个版本的同名 .dcp 文件路径冲突会导致 IDE 加载到旧文件。3.2 首个最小连接TUniConnection 五句话连上 MySQL连接是最基础的操作下面这段代码可以在 Delphi 里直接放到按钮事件中测试var UniConn: TUniConnection; begin UniConn : TUniConnection.Create(nil); try UniConn.ProviderName : MySQL; UniConn.Server : 127.0.0.1; UniConn.Port : 3306; UniConn.Database : testdb; UniConn.Username : root; UniConn.Password : 123456; UniConn.Connected : True; if UniConn.Connected then ShowMessage(已连接数据库版本 UniConn.ServerVersion); finally UniConn.Free; end; end;这段代码做的事很简单创建一个独立的连接对象设置 MySQL 驱动和网络参数把 Connected 置为 True 时触发真实连接。ServerVersion 在连接成功后才能读取未连接时读取会抛异常。注意 TUniConnection 的实例所有权这里用 Create(nil) 创建后由 finally 中的 Free 释放避免窗体关闭后对象泄漏。参数说明ProviderName 决定加载哪个 ProviderServer 支持 IP、主机名MySQL 还支持本地 socket 路径Port 不填时使用数据库默认端口MySQL 是 3306Database 在 MySQL 里对应 schema 名不是服务器的数据库实例名。等价写法是用 ConnectString 一次性赋值UniConn.ConnectString : ProviderNameMySQL;Server127.0.0.1;Port3306; Databasetestdb;UserNameroot;Password123456; UniConn.Connected : True;两种写法最终效果一样但注意不要混用。ConnectString 赋值后再单独改 ProviderName 会清空已有的连接参数因为组件把 ConnectString 解析出的结果和属性是同一份内部状态。我自己的习惯是程序里用属性赋值便于逐项调试需要把整串存到 INI 或注册表时用 ConnectString方便运维直接改文本。设计期连接也值得养成习惯在窗体上放一个 TUniConnection右键 Edit Connection 填好参数并测试连接测试通过后设计器会把连接参数写进 .dfm 文件。这样开发时拖一个 TUniQuery 设置 Connection 指向它在设计器里就能直接预览数据减少很多重复输入连接参数的次数。4. 换库不换代码连接参数对照与四种方言差异处理4.1 常用数据库连接参数对照表UIniDAC 5.3.9 覆盖的数据库很多实际项目里最常碰的无非是下面这几种。整理成表格方便直接对照ProviderName默认端口Server 写法Database 含义注意事项MySQL3306IP 或主机名schema 名直连模式可减少部署依赖PostgreSQL5432IP 或主机名数据库名客户端库版本需与协议匹配SQL Server1433实例名或 IP数据库名走 OLEDBWindows 认证可留空密码Oracle1521IP 或主机名服务名或 SID混用 TNS 时配置在 tnsnames.ora每个 Provider 还有一些专属参数放在 SpecificOptions 属性下例如 MySQL 的压缩协议、SQL Server 的加密选项。5.3.9 里 SpecificOptions 的属性名与其他版本略有出入集成时以随包帮助文档对应章节为准。我的建议能不改 SpecificOptions 就不改默认项经过官方验证改动前先确认目标数据库版本的兼容性。Port 参数有一个常见的误用SQL Server 的实例名会被误当成端口。SQL Server 默认实例走 1433具名实例通常由浏览器服务动态分配端口UniDAC 通过 OLEDB 连接具名实例时最稳妥的方式是在 Server 里写“IP\实例名”由 OLEDB 驱动自己查找端口而不是手动指定一个可能已经变化的端口号。4.2 换库后最容易翻车的四个地方第一个是自增主键获取。MySQL 用 LAST_INSERT_ID()PostgreSQL 的 INSERT 可以带 RETURNING 子句SQL Server 用 SCOPE_IDENTITY()。不同库必须分支处理case UniConn.ProviderName of MySQL: begin UniQuery.SQL.Text : INSERT INTO users(name) VALUES(:name); UniQuery.ExecSQL; UniQuery.SQL.Text : SELECT LAST_INSERT_ID(); UniQuery.Open; NewID : UniQuery.Fields[0].AsInteger; end; PostgreSQL: begin UniQuery.SQL.Text : INSERT INTO users(name) VALUES(:name) RETURNING id; UniQuery.Open; NewID : UniQuery.Fields[0].AsInteger; end; end;这个分支必须在同一个连接上执行跨连接调用会拿不到任何值因为 LAST_INSERT_ID 和 RETURNING 都与当前会话绑定。如果你需要把这段逻辑封装成公共函数记得把 TUniConnection 作为参数传入而不是在函数内部新建连接。第二个是分页。MySQL 写 LIMIT offset,countPostgreSQL 写 LIMIT count OFFSET offsetSQL Server 在 2012 之前的版本用 ROW_NUMBER 包一层2012 之后可以用 OFFSET FETCH。这些语法差异没法靠 UniDAC 自动消除建议把分页 SQL 集中封装在数据访问层每个库维护一套业务层不感知。第三个是参数符号。UniDAC 统一用 :Name 形式命名参数写参数化查询很方便。但当 SQL 文本里出现数据库自身的变量冒号比如 PostgreSQL 的类型转换语法 ::type组件解析时会误认为是参数声明导致执行时报“缺少参数”。解决办法是对连续冒号转义或者把这类 SQL 放到 Provider 分支的原生语句里执行不让它在通用解析路径上跑。第四个是布尔类型。MySQL 的 TINYINT(1) 不会被 UniDAC 自动映射成 Boolean默认读出 IntegerPostgreSQL 有原生 BooleanSQL Server 用 BIT。如果业务代码里需要统一的布尔判断我建议读出来全部当整型处理或者在建表时把所有布尔字段统一成 BIT/BOOLEAN避免同一个字段在不同的库里读出的类型不一致把判断逻辑写到数据库之外的公共函数里。5. UniDAC 5.3.9 避坑指南安装、驱动与字符集的三类翻车现场5.1 安装与驱动相关的两个坑先说安装的坑。现象是点 Install 后组件面板里没有 UniDAC 页IDE 提示安装成功但 Component Palette 里翻不到。原因是装错了包文件或者 IDE 缓存了旧的 bpl 信息。解决方法是把 bpl 相关临时文件清掉确认当前打开的是匹配 IDE 版本的运行期包重新编译然后再 Install 设计期包。如果还不行检查 IDE 的 Library 路径里是不是存在新旧两套同名 .dcp路径优先级会让 IDE 加载到旧文件。再说驱动库的坑。现象是开发机连接 MySQL 一切正常程序发布到客户机执行到 Connected : True 时报“无法加载驱动库”或“初始化失败”。原因是开发机装了 MySQL 客户端软件客户机没有对应的动态库。解决方法是把匹配程序位数32 位或 64 位的动态库放到 exe 同目录同时检查目标机器是否缺少 VC 运行库有些数据库客户端库依赖特定 VC 运行库系统缺了会弹 0xc000007b 错误。5.2 数据正确性相关的三个坑自增字段取回 0。现象同一连接上刚插入记录SELECT LAST_INSERT_ID() 返回 0偶尔又是正确的。原因LAST_INSERT_ID 是基于连接会话的插入和查询如果不是同一条连接或者连接在两次操作之间被断开重连过会话就消失了。解决插入和取 ID 必须用同一个 TUniConnection并且放在同一个事务里如果用了连接池不要指望池子里拿出的条连接一定和上次是同一个。Oracle 换台机器就连不上。现象开发机用服务名连接没问题部署到另一台机器报 TNS 无法解析服务名。原因连接串里只写了 Database 服务名没写服务器地址路由依赖的是目标机器上的 tnsnames.ora。解决连接串里显式写 Server、Port、Database绕过 TNS 文件如果项目规范要求用 TNS就把 tnsnames.ora 一起部署并设置好环境变量而不是让每台机器手动配。PostgreSQL 中文乱码。现象同一套代码SQL Server 下中文正常PostgreSQL 读出来是乱码。原因UniDAC 客户端字符集与 PostgreSQL 服务端字符集不一致。解决建库时统一指定 UTF8连接建立后在会话里执行 SET NAMES 语句或通过 SpecificOptions 设置字符集。写入和读取两侧都要一致只改一侧是治标不治本。提示UniDAC 的字符集问题在 5.3.9 上普遍存在根因大多不是组件 Bug而是数据库端的字符集规划。建库前就把字符集定下来比事后改连接参数靠谱得多。6. 把 5.3.9 用成工程标配三个习惯与验证方法6.1 把连接配置放到外部文件切库不用重新编译工程里最该做的一件事是让 ProviderName 和连接参数从代码里走出去。常见做法是读取一个 INI 文件UniConn.ProviderName : Config.ReadString(db, provider, MySQL); UniConn.Server : Config.ReadString(db, server, 127.0.0.1); UniConn.Port : Config.ReadInteger(db, port, 3306); UniConn.Database : Config.ReadString(db, database, testdb); UniConn.Username : Config.ReadString(db, username, root); UniConn.Password : Config.ReadString(db, password, ); UniConn.Connected : True;这样从 MySQL 切到 PostgreSQL只需要改 INI 里的 provider、port 和连接地址程序代码一行不动。坏处是原来编译期就能发现的连接错误变成了运行期问题所以配套的验证步骤就很重要。6.2 建一个方言自检用例换库前先跑一遍我给每个工程都留一个连接自检界面界面上一排按钮分别执行增删改查、自增获取、分页查询、日期时间读取。切换数据库后按顺序点一遍把每个按钮的结果记下来。自检覆盖的范围不需要很大但必须把业务里用到的所有方言差异点都包含进去。跑一遍自检半小时内就能知道这个库能不能接得住现有代码。很多看起来玄学的换库故障其实在这个环节就能暴露出来。我自己的习惯是每次拿到新环境或新库先跑自检再跑业务接口联调。这个习惯帮我挡住了几次“代码看起来没问题但一上线就出乱子”的风险。UniDAC 5.3.9 不是万能解药它把数据库差异收敛到了连接层和 SQL 管理但业务里的方言分支始终要靠人维护。把这些分支集中管理、定期自检这组件的价值才算真正用满希望帮到你。本文还有配套的精品资源点击获取