企业官网建设流程全解析

简介：UniDAC 10.3.0 for D13 FS 是专为 Delphi 13.0 FireMonkey 框架设计的数据库访问组件完整源码版，通过统一接口连接 Oracle、SQL Server、MySQL、PostgreSQL、SQLite 等主流数据库，免去为每种数据库单独适配的重复工作，适合需同时管理多种数据库、并面向 Windows、macOS、Linux 及 iOS/Android 跨平台交付应用的 Delphi 开发者。资源包约 12.19MB，共 938 个文件，其中 557 个 pas 源文件构成核心实现，dpk/lpk 负责工程与包定义，dfm/lfm 保存界面，inc/res 提供配置与资源，另有少量 dll/so/dylib 动态库，整体结构完整，便于二次编译与集成。压缩包附带安装工具，解压后即可在 IDE 组件面板中调用各数据库驱动，拖拽组件完成连接配置，已有 271 人学习下载。功能上，除基础连接外，组件还提供批量更新、参数化 SQL、宏替换、事务自动恢复等企业级特性；配合完整源码，可深入追踪底层实现，理解数据库访问运行机制，并利用跨平台工程模板快速构建多端应用。对希望统一数据访问层、减少多数据库适配成本的中高级 Delphi 开发者，这套源码版是实用的基础组件，尤其适合长期维护、二次扩展和深度定制的项目。

1. 当 UniDAC 10.3.0 for D13 源码包摆在你面前：它到底解决了什么

UniDAC 10.3.0 for D13 完整源码版附带安装工具，这个标题已经把三层信息点透了：UniDAC 是 Devart 出品的通用数据库访问组件，10.3.0 是当前较新的功能主线，D13 表示这套包面向较新的 Delphi 开发环境；而“完整源码版”意味着你不只拿到预编译的 bpl/dcu，还拿到全部单元源码，再配合安装工具完成解压、选择 IDE 版本、编译包、注册设计期组件这一整套动作。对开发团队来说，它的核心价值集中在一点：在同一个 IDE 里用同一套组件连接 SQL Server、MySQL、PostgreSQL、SQLite，应用层代码不随数据库驱动来回换。适合正在维护多数据库项目的 Delphi 工程师，也适合需要在离线环境重新编译组件、或者想进组件内部排查问题的熟手。

2. 先看懂 UniDAC 的组成和技术选型：为什么源码版值得这样做

2.1 UniDAC 不只是一个 TUniConnection

很多第一次接触 UniDAC 的开发者，以为装上之后只是多了个数据库连接控件。实际打开设计期面板，你会看到一整组 Uni 前缀的控件，它们合在一起才构成 UniDAC 的完整能力。

TUniConnection 是所有连接操作的入口，ProviderName 属性决定当前会话走哪套驱动；TUniQuery 负责参数化查询和结果集遍历，比直接拼 SQL 更安全；TUniTable 适合对单表做增删改查；TUniScript 用来执行多语句的 DDL 脚本；TUniDump 做数据库转储和恢复；TUniMetaData 能读取表结构、索引、外键等元数据；TUniSQLMonitor 负责把每次执行的 SQL 和耗时记录下来，生产环境排查慢查询很管用；TUniTransaction 把分布式事务显式管理起来。

这个组件家族的覆盖范围，决定了你在项目里几乎不需要再引入第二套数据库访问库。从数据访问层角度看，一套 UniDAC 已经覆盖了日常开发的所有姿势：连接、查询、脚本、元数据、监控、事务。

2.2 “完整源码版”到底多了什么

普通商业组件安装包通常只给编译好的 bpl 和 dcu，你能拖控件、能编译，但看不到内部实现。UniDAC 10.3.0 for D13 这种“完整源码版”里，你会看到 Source 目录下按单元拆开的源码文件，比如 Uni.pas、UniProvider.pas、UniSQLServer.pas 这些。

有源码带来几个实际好处。第一是排障时可以直接单步跟进组件内部，看它在 Prepare、Execute、Fetch 三个阶段分别做了什么，而不是把连接失败的问题当成黑匣子反复试连接串参数。第二是你可以自己编译针对当前 IDE 版本的包，不依赖安装工具是否已经适配。第三是能改动源码里的默认行为，比如调整超时计算逻辑、打印更多调试信息，这在用官方预编译包时是做不到的。

配套的安装工具也不是简单把 dcu 复制进 Library 目录。它要做的是：识别你本机的 Delphi 版本，把对应后辍的包打开，编译 runtime 包，再编译 design-time 包并注册到 IDE。这个过程如果不理解，后面遇到“面板里没有控件”“编译提示找不到 dcu”这类问题时就会无从下手。

2.3 和 FireDAC 摆在同一张桌上，我为什么选 UniDAC

Delphi 自带 FireDAC，功能也很完整，很多项目不需要额外引入 UniDAC。但实际选型时，我见过不少团队在两套方案之间反复横跳。UniDAC 的核心优势在于它对开发环境的绑定更松：同一套组件代码可以跨 Delphi、C++Builder、Lazarus 使用，甚至 Lazarus 用户也在用 UniDAC，这在社区里是很常见的搜索词“lazarus 安装 unidac”背后反映的真实需求。

另一个理由是版本行为的一致性。FireDAC 会随 RAD Studio 版本更新改变一些底层行为，升级 IDE 后可能要重新回归测试数据库访问层。UniDAC 的版本节奏相对独立，10.3.0 在 D13 上的表现和它在旧版本上的行为差异更可控，升级时你有源码可以看变更点。

当然，代价是 UniDAC 是商业组件，需要授权。如果你所在团队已经在用这套体系，源码版能帮你把底层的连接逻辑彻底吃透，而不是停留在“能用就行”的状态。

3. 从 7z 压缩包到 D13 设计期面板：安装流程能直接抄

3.1 解压并确认目录结构，再开始安装

拿到手的是一个 7z 压缩包，第一步不是双击运行什么 exe，而是先解压并看清楚内部布局。你需要在命令行里把包解开，避免解压过程中因为中文文件名导致路径错乱。

# 用 7-Zip 命令行解压，-o 指定输出目录，-y 覆盖确认 & "C:\Program Files\7-Zip\7z.exe" x "D:\downloads\UniDAC10.3.0_for_D13_FS_source.7z" -o"D:\DevTools\UniDAC10.3.0" -y # 查看顶层目录，通常会有 Source / Lib / Demo / Install 等目录 Get-ChildItem "D:\DevTools\UniDAC10.3.0" | Select-Object Name, Mode

这段命令里，x表示解压，-o后紧跟输出目录，-y表示遇到已存在文件自动覆盖。解压目录我建议放在纯英文路径下，因为后面编译时 Delphi 的 IDE 对中文路径虽然能处理，但一旦涉及 bpl 注册和 Library 路径配置，中文路径偶尔会引发奇怪问题，实在没必要赌这个概率。

解压完成后先看一眼顶层目录。常见的布局是 Source 放源码、Lib 放预编译 dcu、Install 放安装工具、Demo 放示例工程。如果 Install 目录存在，说明标题里说的“附带安装工具”确实在，接下来优先用安装工具流程。

3.2 运行安装工具，完成一次面向 D13 的自动安装

安装工具的名字在不同打包版本里不一样，可能是 InstallDAC.exe、SetupUniDAC.exe 这类名字。我不建议你凭固定印象双击某个 exe，而是用 PowerShell 去扫描目录里的可执行文件，再把真正的主程序找出来。

# 在安装目录中查找候选的安装/卸载主程序 $setup = Get-ChildItem "D:\DevTools\UniDAC10.3.0" -Recurse -Include *.exe | Where-Object { $_.Name -match 'Install|Setup' } | Select-Object -First 1 # 使用管理员权限启动安装工具 if ($setup) { Start-Process $setup.FullName -Verb RunAs } else { Write-Host "没找到安装主程序，改走手动编译流程" }

这段脚本先把匹配 Install 或 Setup 的 exe 找出来，再用管理员权限启动。需要说明的是，Start-Process -Verb RunAs会弹出 UAC 确认，这是安装组件注册 bpl 所必需的，不要跳过。

安装工具打开后，界面上通常有几个关键选项。IDE 版本下拉列表里会列出一串版本代号，D13 指的是以 Delphi 13 为目标的那一组包；如果你的本机 IDE 不叫这个名字，就选对应内核版本最接近的项。接着选要安装的驱动，建议初期全选，因为官方包本身不大，缺一个驱动以后再回来补装反而麻烦。再往下是 runtime 和 design-time 两组包，设计期包必须勾选，否则组件面板里不会出现控件。

3.3 不依赖安装工具：手动编译和注册设计时包

有时候安装工具界面里的版本列表和你本机的 IDE 对不上，或者工具本身抽风点不了下一步。这时不要卡住，直接手动编译。

# 先加载 Delphi 环境变量，再编译运行时包和设计时包 call "C:\Program Files (x86)\Embarcadero\Studio\24.0\bin\rsvars.bat" msbuild "D:\DevTools\UniDAC10.3.0\Packages\D13\unidacRuntime.dproj" /p:Platform=Win32 /p:Config=Release /v:minimal msbuild "D:\DevTools\UniDAC10.3.0\Packages\D13\dclUniDAC.dproj" /p:Platform=Win32 /p:Config=Release /v:minimal

这段命令里的关键点是rsvars.bat，它会帮你在命令行环境里搭好 BDS、Platform、Library 路径等变量，不执行它直接 msbuild 大概率报找不到 IDE 工具链。后面的unidacRuntime.dproj是运行时包工程，dclUniDAC.dproj是设计期包工程。设计期包编译成功后，正常会自动注册到 IDE，如果没注册，你可以在 Delphi 的 Component > Install Packages 里手动添加 dcl 开头的 bpl。

包名称不一定完全叫unidacRuntime和dclUniDAC，要看解压目录里的实际文件。动手前先打开 Packages 目录看一眼文件名，按真实名称替换命令里的工程名。

3.4 安装完成后需要确认的三处路径

不管用安装工具还是手动编译，装完后都要确认三个地方，缺一处后面必然踩坑。

我习惯在装完后先不开自己的项目，而是新建一个空 VCL 工程，往窗体上拖一个 TUniConnection。这一步验证的是设计期组件是否注册成功，比直接打开老项目排错要快得多。

4. 在 D13 工程里跑通第一个 UniDAC 查询：连接串与参数

4.1 最小连接代码：三行打开 SQLite

安装完成后，第一个目标不是复杂业务，而是用最简单的方式确认组件能打开连接并读取数据。SQLite 是最容易做验证的数据库，因为它不需要额外启动服务，本地一个文件就能跑。

// 在 FormCreate 里打开 SQLite 连接，路径按实际文件修改 UniConnection1.ProviderName := 'SQLite'; UniConnection1.Database := 'D:\data\demo.db'; UniConnection1.Open;

这三行代码建立了从 Delphi 到 SQLite 的完整链路。ProviderName 决定驱动加载行为，Database 是 SQLite 的文件路径。Open 调用后如果没抛异常，说明组件安装、驱动加载、库文件路径都是通的。SQLite 的驱动在 Windows 上一般依赖 sqlite3.dll，如果 Open 报找不到库，第一反应不应该是改连接串，而是检查 dll 是否放在可执行文件目录或系统 PATH 中。

4.2 三种常见数据库的连接参数对照

实际项目里 SQLite 只能算开胃菜。开发环境用 SQLite，测试环境切到 SQL Server 或 MySQL，这是很多团队的工作流。下面这张表把三者的关键参数列出来，方便迁移时对照。

这里需要注意一个常见误会：UniDAC 的连接串不是必须写在代码里。设计期你可以右键 TUniConnection 打开编辑器，填好参数后点击 Test 按钮验证，连接串会自动保存到组件属性里。代码里只需要在运行时改 Server、Database 等少数几个字段即可，不要把整个连接串硬编码进单元文件。

4.3 参数化查询和结果集遍历

连接建立后，最常用的操作就是带参数的查询。用参数而不是字符串拼接，不只是为了防注入，更重要的是 UniDAC 可以对同一句 SQL 做 Prepare 复用，性能上更稳。

// 设置 UniQuery 关联到已打开的连接 UniQuery1.Connection := UniConnection1; // 用命名参数 :deptId 过滤部门，避免直接拼字符串 UniQuery1.SQL.Text := 'SELECT id, name, created_at FROM users WHERE dept_id = :deptId'; UniQuery1.ParamByName('deptId').AsInteger := 10; // 执行查询并遍历结果集 UniQuery1.Open; try while not UniQuery1.Eof do begin // 这里通过 FieldByName 取字段值，交给界面控件展示 UniQuery1.Next; end; finally UniQuery1.Close; end;

这段代码的关键点是ParamByName('deptId').AsInteger := 10。UniDAC 的命名参数使用冒号前缀写在 SQL 里，赋值时用 ParamByName 指定参数名，不能带冒号。Open 方法执行的是返回结果集的查询，如果你要执行 UPDATE、INSERT 这类写操作，应该用 ExecSQL 而不是 Open，这是一个新手最容易犯的区别。

在循环体内，建议先取字段值存到局部变量再 Next，不要在 Next 之后再访问当前行字段，否则会丢一行数据。

4.4 高频参数：Pooling、Charset、Timeout

连接串里还有三个参数值得花时间调明白。

Pooling 决定连接是否复用，默认有很多驱动是开启的。在 Web 服务场景里，频繁建立物理连接很贵，开 Pooling 能明显减少握手次数；但在批量任务里，长连接池反而会占用数据库连接数，这时可以关闭。

Charset 和 UseUnicode 是针对字符集问题的组合拳。MySQL 用 UTF-8 时，连接串里要同时确认 Server 的字符集和客户端的 Unicode 设置，否则中文字段读出来可能是乱码。SQL Server 情况复杂一些，但核心原则是统一用 UTF-8 或 Unicode 模式，不要让数据库端和应用端各用各的编码。

ConnectTimeout 是连接超时，在数据库服务启动慢或网络抖动时很有用。默认值可能让你等很久才报错，设置成 5 到 15 秒，可以在服务不可用时快速失败，把错误信息反馈给用户而不是让界面一直转圈。

5. UniDAC 安装与连接避坑：5 个我不能不说的真实问题

5.1 组件面板里看不到 Uni 开头的控件

现象：安装工具跑完或者手动编译完成，打开窗体设计器准备拖 TUniConnection，但组件面板里找不到 Uni 相关分类。

原因：设计期包 dcl 开头的 bpl 没有注册成功，或者注册了但 IDE 缓存没有刷新。常见于安装工具在 IDE 仍然运行时执行，bpl 被锁定没写进去。

解决：先完全关闭 Delphi，确认任务管理器没有残留 bds.exe 进程，再重跑一次安装工具或手动注册设计期包。如果还不行，在 Delphi 里打开 Component > Install Packages，点 Add 手动浏览到 dclUniDAC 开头的 bpl 文件。安装完成后重启 IDE，这招能解决 80% 的“找不见控件”问题。

5.2 打开连接时提示 Provider not found

现象：编译正常，运行到 Open 时突然抛异常，提示指定的 Provider 没有找到或者无法加载。

原因：ProviderName 写错是低级的可能性，最常见的还是驱动对应的 dcu 或 bpl 没有进入运行路径。比如你装的是 D13 包，但工程里把 IDE 版本选成了旧的，编译产物用的是旧路径。

解决：先在 IDE 的 Library 路径里检查源码和 Lib 目录是否指向 D13 对应的子目录；再确认 ProviderName 字符串和安装工具的驱动列表里的名称严格一致，注意大小写。我自己遇到过把SQL Server写成SQLServer，组件直接不识别的翻车案例，这种错查连接串时特别容易忽略。

5.3 提示缺少 sqlite3.dll 或其他本地库

现象：SQLite 连接在开发机上正常，拷贝到另一台机器后 Open 报找不到指定模块，或者直接弹 Windows 错误框。

原因：UniDAC 的 SQLite 驱动是 Bridge 方式，底层仍然依赖 sqlite3.dll。开发机装了完整环境所以有 dll，目标机器没有做依赖收集。

解决：把 sqlite3.dll 放到 exe 同目录，或者放到系统目录并确保 PATH 能找到。64 位目标程序必须放 64 位版本的库，32 位程序对应 32 位版本，两者混用会报 bad image 错误。我通常在项目里建一个 ThirdParty 目录，编译后事件把对应平台的 dll 复制到输出目录，从根上避免手工拷漏。

5.4 源码版覆盖安装后出现旧 DCU 冲突

现象：从旧版本升级或者在同一台机器装了两套不同路径的 UniDAC，编译时提示某个 dcu 版本不匹配，或者运行时出现 Access Violation。

原因：Delphi 的 Library 路径里先找到的 dcu 会覆盖后找到的。老的 UniDAC 路径排在前面，导致源码里用的是新头文件，实际编译链接的却是老 dcu，两边对不上。

解决：在 IDE 的 Library 路径里把旧版本的 UniDAC 目录删除，只保留新版的 Source 和 Lib 路径，并保证新版路径排在前面。删除所有 DCU 缓存后全量重新编译。如果项目工程里不小心把旧版本的源文件加入进来，也要一并移除。为了不留后患，我一般把安装工具做的一键安装看成“第一遍”，随后手动核对一遍路径才算真正装完。

5.5 中文字段读出乱码

现象：数据库存储的中文在界面控件里显示成问号或乱码，但直接拿数据库客户端工具查询却是正常的。

原因：连接层字符集没有对齐，客户端和服务器两端一个用 UTF-8，一个用 GBK，转换链路上出现了断层。

解决：在 UniConnection 属性里设置 Charset 和 UseUnicode，MySQL 一般设置 Charset 为 utf8mb4 并开启 UseUnicode；SQL Server 则关注客户端代码页。设置完重新连接，并查一下数据库层面的字符集排序规则，让整条链路统一，不能在应用层用 UTF-8，数据库列却还是 Latin-1。

6. 更稳妥的升级路径：从源码重建、迁移与验证

安装工具帮你处理的是绝大多数标准场景，但如果你本机的 IDE 版本和包里的 D13 目标不完全对应，我会建议直接走源码重建这条路。打开 Packages 目录，找到和目标 IDE 版本最接近的 .dproj 工程，用 rsvars.bat 初始化环境后 msbuild 编译，再把产物目录加到 IDE 的 Library 路径里。这种方式看起来比安装工具多花十几分钟，但你能清楚看到编译过程到底做了什么，后续再遇到问题不会慌。

把已有项目从 FireDAC 或 ADO 迁移到 UniDAC 时，不要一次性把数据库层全部重写。我习惯先建一个独立的数据访问模块，Module 里只放 UniDAC 组件和相关函数，外部界面依赖接口而不是直接持有控件。这样迁移时可以先并行跑老方案和新方案，对比查询结果一致后再切换。连接串映射上，FireDAC 的 DriverID 换到 UniDAC 的 ProviderName，数据库账号密码字段基本一一对应，比很多人想象的要平滑。

我还保留着一个长期习惯：每次装完新版 UniDAC 之后，除了空工程拖一个 TUniConnection 验证设计期组件外，还会强制写一个最小数据库测试脚本，分别连接 SQLite 和 SQL Server，执行一次参数化查询，确认 32 位和 64 位两个编译目标都能通过。这套流程平时感觉多余，但等到真要交付给现场部署时，它能帮你避开大量“在我机器上能跑”的尴尬。希望这篇落地笔记能帮你在 D13 上把 UniDAC 真正用起来，少走我绕过的那些弯路。

本文还有配套的精品资源，点击获取