簡介這是一套面向 Delphi 12、Free Pascal Compiler 3.3.1 與 Lazarus 3.9.9 開發(fā)環(huán)境的 UniDAC 10.3 完整源代碼包目標用戶聚焦于對數(shù)據(jù)庫訪問層有定制需求或希望深入組件原理的 Delphi 開發(fā)者。壓縮包總計 2000 個文件核心為 1960 個 hpp 頭文件配合少量 cpp 源文件、sql 腳本、txt 說明、xml 配置及 html 文檔整體體積 231.35MB。目錄結構按功能劃分Source 存放可讀的組件實現(xiàn)Demos 提供可直接運行的示例程序Include 與 Lib 輔助編譯和最終部署Doc 與 History 分別收錄參考文檔和版本更新記錄DbToolsInterfaces 定義數(shù)據(jù)庫工具接口Http 補充網(wǎng)絡通信能力。目前已有 139 人瀏覽學習適合具備一定開發(fā)經(jīng)驗、需要快速掌握跨數(shù)據(jù)庫統(tǒng)一訪問方案或進行底層定制的學習者。通過安裝說明、示例程序與源碼解讀學習者不僅能系統(tǒng)理解連接管理、SQL 執(zhí)行與事務處理等核心機制還能在實際項目中集成或進行二次開發(fā)。1. 一份源碼版的 delphi 控件包拿到 UniDAC 10.3 先想清楚三條線Delphi 控件源碼包看多了之后我拿到 UniDAC 10.3 這份帶D12-fpc331-Laz399-20241005-ok后綴的資源第一反應不是雙擊安裝而是先把它當作一個待拆的工程來看。這個后綴含義很直白它能同時適配 Delphi 12、Free Pascal 3.3.1、Lazarus 3.99 三條編譯線。對只想裝個控件連數(shù)據(jù)庫的開發(fā)者來說源碼版看著勸退但對要維護跨平臺桌面程序、又不想被安裝包黑匣子綁架的人來說這份資源恰恰能把數(shù)據(jù)庫訪問層的編譯細節(jié)打開給你看。它適合動手派不適合只點下一步的人。下面是我拆包、編譯、踩坑的完整記錄。2. UniDAC 10.3 源碼包結構拆解先分清楚 Delphi 12 和 Lazarus 兩條編譯線2.1 目錄布局一份源碼包兩條編譯線拿到源碼包之后別急著打開 Delphi 12先用文件管理器把整個目錄結構過一遍。我一般會先看有沒有Source根目錄再看里面是否有Delphi12、Laz、FPC這類明顯按工具鏈劃分的子目錄。常見布局大致如下UniDACSource ├── Source │ ├── Core # 核心運行時單元 │ ├── Providers # 各家數(shù)據(jù)庫驅動實現(xiàn) │ ├── Delphi12 # Delphi 12 專用 dpk 工程 │ ├── Delphi10 # 老版本 Delphi 分支可忽略 │ └── Laz # Lazarus 的 lpk 包工程 ├── Lib │ ├── D12 # Delphi 12 編譯產(chǎn)物輸出 │ └── Laz # Lazarus 編譯產(chǎn)物輸出 ├── sqlite3.dll # 本地 SQLite 驅動庫按需放置 └── ReadMe.txt這份源碼包里的Source\Core和Source\Providers是兩個最關鍵的位置。Core放的是 UniDAC 的抽象層單元比如連接對象、命令對象、事務對象的基類定義Providers下則是各類數(shù)據(jù)庫的具體實現(xiàn)Oracle、SQL Server、MySQL、PostgreSQL、SQLite 各占一個目錄。目錄名里的fpc331和Laz399表示這套源碼同時帶了 Free Pascal 3.3.1 和 Lazarus 3.99 的工程文件不是只能給 Delphi 12 用。我通常會先看ReadMe.txt和Source\Delphi12下的.dpk文件數(shù)量。.dpk文件是 Delphi 的包工程文件一個控件包往往拆成運行時包和設計時包兩個甚至更多。如果Delphi12目錄下只有一個.dpk往往說明作者把運行時和設計時合并在一起了安裝會簡單些如果拆成多個比如dclUniDAC和UniDAC編譯順序就要注意這個坑后面會專門說。2.2 運行時包與設計時包的分工先厘清編譯順序UniDAC 這類控件在 Delphi 里安裝時背后涉及兩類包運行時包Runtime Package和設計時包Design-Time Package。運行時包是程序運行時要加載的里面是真正的業(yè)務邏輯單元比如TUniConnection、TUniQuery這些類的實現(xiàn)設計時包則是給 IDE 本身用的里面主要是組件注冊代碼負責讓控件出現(xiàn)在工具面板上并串聯(lián)屬性編輯器。這兩類包有嚴格的依賴順序必須先編譯運行時包并安裝它再編譯設計時包。因為設計時包源碼里uses了運行時包的單元編譯時需要能找到對應的.dcu或.bpl文件。順序反了最常見的報錯是Unit not found或者Cannot load package。從資源落地角度講我們下載這套源碼不是看它能不能裝上而是理解它背后這套依賴鏈出問題時才知道往哪查。我把這個順序總結成一句口訣先Build運行時再Install設計時。Build是編譯但不安裝Install是把包注冊進 IDE。順序錯了IDE 的組件面板上要么什么都不出現(xiàn)要么出現(xiàn)一堆帶問號的錯誤項。2.3 源碼版和安裝版怎么選邊界在哪里很多開發(fā)者的第一反應是向別人要一個別人裝好的安裝版雙擊下一步完事。但安裝版有個天然問題它往系統(tǒng)里塞了注冊表項、服務、全局路徑換臺機器重裝一遍或者換個 IDE 版本之前裝的控件就變成黑匣子出了問題很難查。源碼版的好處是每條編譯路徑都攤在你面前dpk文件里寫了哪些單元參與編譯條件編譯指令里定義了哪些版本分支全都能看到。但這不意味著源碼版適合所有場景。如果只是在固定的 Delphi 12 環(huán)境里做一個小工具安裝版確實更省事如果像這個資源標題一樣明確帶了fpc331和Laz399說明發(fā)布者的意圖就是讓你在多個 IDE 生態(tài)里復用同一套代碼。這種情況下源碼版的優(yōu)勢就出來了同一個TUniConnection單元Delphi 12 下編譯一次拿到 Lazarus 3.99 里用.lpk工程再編譯一次業(yè)務代碼不用動。我個人的習慣是只要是跨平臺項目一律用源碼版并且把源碼包放到固定目錄比如D:\Libs\UniDAC不要放在項目目錄里。這樣多個工程可以共用一份編譯好的.dcu不會出現(xiàn)每個工程都復制一份源碼導致版本漂移的問題。3. 在 Delphi 12 里把 UniDAC 編譯安裝起來從 Library Path 到最小連接驗證3.1 編譯前的庫路徑與條件編譯在 Delphi 12 里編譯 UniDAC 之前第一步是把源碼目錄加到 IDE 的搜索路徑里。打開Tools Options Delphi Options Library在Library Path里把Source\Core和Source\Providers加進去。注意這里不要加Source\Delphi12因為那個目錄里放的是.dpk工程文件不是單元源碼加了反而會讓 IDE 在啟動時嘗試加載多余文件拖慢速度。這套源碼在 Delphi 12 下編譯時會走條件編譯分支。源碼里通常會有類似下面的判斷{$IF Defined(VER360)} // Delphi 12 Athens 對應的編譯器版本 {$DEFINE UNIDAC_D12} {$ENDIF}這個代碼塊的作用是在編譯期根據(jù) Delphi 編譯器版本號決定是否定義UNIDAC_D12這個編譯符號。實際版本號取決于你裝的 Delphi 12 更新包打開 IDE 后按CtrlAltE或查看About窗口里的編譯器版本就能確認對應值。如果你在源碼里看到了類似的IF Defined指令不要手欠去改它默認分支通常已經(jīng)覆蓋了當前版本。加完路徑后先做一次干凈編譯檢查打開Project Manager看左側樹里有沒有報紅叉的節(jié)點。如果一切正常再進行包的編譯。這一步我習慣單獨花十分鐘做不著急點Build因為路徑配錯了后面的報錯會連成一片很難定位根因。3.2 編譯運行時包與設計時包的正確順序把源碼包加載進 Delphi 12 的方式很簡單File Open定位到Source\Delphi12目錄打開里面的.dpk文件。打開后Project Manager會把它當作一個包工程顯示。這時先看包的名字以dcl開頭的通常是設計時包不帶dcl的是運行時包。如果兩個文件都有先處理不帶dcl的那個。我一般會用命令行方式編譯界面操作雖然直觀但命令行能穩(wěn)定復現(xiàn)步驟。打開 Delphi 自帶的命令行環(huán)境進入源碼目錄執(zhí)行類似下面的命令dcc32.exe -B -Q -DD12 UniDAC.dpk dcc32.exe -B -Q -DD12 -LU dclUniDAC.dpk第一行-B表示全量重新編譯-Q靜默模式減少輸出干擾-DD12是定義編譯符號對應源碼里D12分支第二行里的-LU表示編譯設計時包時鏈接運行時包。實際執(zhí)行時.dpk文件名需要以源碼目錄里的實際文件名為準不要照抄。如果你不習慣命令行也可以在 IDE 里操作先右鍵運行時包選擇Build再右鍵設計時包選擇Build最后對設計時包選擇Install。這里有個容易誤解的細節(jié)Build和Compile不是一回事。Build會重新編譯所有單元不管有沒有變化Compile只編譯有改動的。從網(wǎng)上下載的源碼包目錄里可能殘留著舊.dcu文件所以第一次必須用Build否則可能出現(xiàn)編譯“成功”但實際跑的還是舊代碼的情況。3.3 用 TUniConnection 驗證安裝結果編譯安裝完組件面板上出現(xiàn)UniDAC選項卡之后不要急著往項目里拖控件。先建一個最小的測試工程用代碼方式驗證安裝結果。新建一個VCL Forms Application放一個按鈕和一個Memo在按鈕事件里寫uses Uni, SQLiteUniProvider, UniProvider; procedure TForm1.Button1Click(Sender: TObject); var Conn: TUniConnection; begin Conn : TUniConnection.Create(nil); try Conn.ProviderName : SQLite; Conn.Database : C:\Temp\test.db; Conn.Connect; Memo1.Lines.Add(連接成功服務端版本: Conn.ServerVersion); finally Conn.Free; end; end;這段代碼的邏輯是創(chuàng)建TUniConnection實例設置ProviderName為SQLite指定數(shù)據(jù)庫文件路徑然后調用Connect建立連接。ServerVersion是連接成功后從驅動層取回的版本字符串能取到就說明整條調用鏈是通的。uses里必須在Uni之后顯式引用SQLiteUniProvider這一點很關鍵——UniDAC 默認不會把所有數(shù)據(jù)庫驅動都鏈接進來少了這一行運行時大概率報Provider not found。跑這個測試之前記得把sqlite3.dll放到exe所在目錄。源碼包自帶的那個sqlite3.dll通常在包的根目錄或Lib目錄下。如果忘了放Connect會直接報錯后面避坑章節(jié)會專門展開。4. 避坑指南UniDAC 在 D12 / FPC / Lazarus 混編時最容易翻車的五個點4.1 運行時包編譯通過設計時包報 Unit not found現(xiàn)象先編譯了運行時包再編譯設計時包結果 IDE 彈窗提示找不到某個.dcu文件。按下F12看錯誤面板報錯的行是設計時包某個單元的uses語句。原因運行時包雖然編譯成功了但.dcu輸出目錄沒有加入到 Delphi 的Library Path里。Build只是生成了文件IDE 在編譯設計時包時還不知道該去哪個路徑找這些.dcu。解決打開Tools Options Delphi Options Library把運行時包設置的Output directory通常在包工程的Project Options里配置加到Library Path?；蛘吒直┑淖龇ò堰\行時包安裝到 IDE 里右鍵Install讓 IDE 自己記錄它的輸出路徑。從那以后我遇到Unit not found第一反應從“代碼寫錯”改成“路徑?jīng)]指對”排查速度快了很多。4.2 連接 SQLite 時報錯無法加載 sqlite3.dll現(xiàn)象編譯、安裝、拖控件都沒問題運行測試工程點按鈕后彈出Could not load sqlite3.dll或類似提示程序在Connect這行中斷。原因這個報錯非常經(jīng)典。UniDAC 的 SQLite 驅動只是一個包裝層真正干活的是 SQLite 官方的sqlite3.dll。源碼包里雖然帶了這份文件但它不會自動復制到你的exe輸出目錄。Delphi 編譯產(chǎn)物和這個 DLL 分處兩個目錄運行時按當前工作目錄找 DLL自然找不到。解決把sqlite3.dll手動復制到exe所在目錄或者放到C:\Windows\System32不推薦污染系統(tǒng)目錄。另一個細節(jié)如果你的工程編譯成 64 位sqlite3.dll也必須是 64 位版本32 位 DLL 在 64 位進程里加載會直接報錯這個坑在換平臺時特別容易踩。4.3 Lazarus 3.99 下編譯 lpk 報錯FPC 3.3.1 分支對不上現(xiàn)象在 Lazarus 3.99 里打開Source\Laz下的.lpk文件點編譯報錯信息指向 FPC 運行時庫的某個單元說簽名不一致或找不到某個聲明。原因這個資源標題里寫的fpc331是 Free Pascal 的 trunk 分支不是穩(wěn)定版Laz399同樣接近開發(fā)主線。trunk 分支的運行時庫經(jīng)常改接口今天能編譯的代碼明天更新 FPC 后可能就報錯。如果 Lazarus 自帶的 FPC 版本和源碼包作者當時用的不完全一致就會撞上這類問題。解決先把 FPC 編譯器路徑指到資源對應的fpc331版本在 Lazarus 的Tools Options Files Compiler Path里確認。如果公司項目里還跑著舊版 Lazarus我的建議是給源碼包單獨準備一套 FPC Lazarus 環(huán)境不要和老項目混用。用Lazarus目錄下的lazbuild.exe命令行編譯可以更快定位問題lazbuild.exe --add-package Source\Laz\UniDAC.lpk lazbuild.exe --build-filetest.lpr--add-package的作用是把lpk包注冊進 Lazarus 的包列表--build-file再對實際工程做編譯這樣報錯時能看到是包本身的問題還是工程引用的問題。4.4 源碼路徑帶中文或空格編譯到一半 IDE 卡死現(xiàn)象把源碼包解壓到D:\下載\UniDAC 10.3\這種帶中文和空格的目錄編譯工程時 IDE 偶發(fā)卡死或報出一些亂碼路徑的錯誤。原因老一批控件源碼在內(nèi)部拼接路徑時還在用AnsiString或char指針中文路徑在 Delph 的默認代碼頁下會編碼錯亂空格則會讓某些內(nèi)部命令行工具把路徑拆成兩段。解決源碼包解壓后直接放在純英文無空格的路徑比如D:\Libs\UniDAC_Source。這個習慣最好在所有第三方控件上統(tǒng)一執(zhí)行不只是 UniDAC。Delphi 自身的Library Path支持帶空格的路徑但第三方控件內(nèi)部處理不一定會考慮到這一點沒必要在這種地方賭運氣。4.5 編譯一切正常運行時提示 Provider not found現(xiàn)象測試工程編譯、運行都正常連接MySQL或PostgreSQL時運行時報Provider not found或Unknown provider。原因和 3.3 里說的一樣UniDAC 的驅動是延遲加載的。源碼包把各種 Provider 都放在Source\Providers里但編譯器不會把用不到的單元鏈接進程序。如果代碼里只uses Uni那程序里就真沒有 MySQL 或 PostgreSQL 的驅動實現(xiàn)。解決在工程主單元的uses里顯式引用對應的 Provider 單元uses Uni, MySQLUniProvider, // 使用 MySQL 時 PostgreSQLUniProvider, // 使用 PostgreSQL 時 SQLiteUniProvider; // 使用 SQLite 時這段代碼的邏輯是告訴編譯器這幾個 Provider 單元必須參與鏈接。這樣TUniConnection在運行時才能根據(jù)ProviderName找到對應實現(xiàn)。從源碼包里也能看到這些單元名Source\Providers目錄下每個子目錄對應一個 Provider單元名稱通常就是數(shù)據(jù)庫名 UniProvider的格式。5. 編譯完先別急著集成驗證最小連接的三個習慣第 4 章五個坑都避開之后編譯安裝這一關算是過了但在把它集成進真實項目之前我強烈建議補一道驗證。不是驗證控件能不能編譯——編譯通過只說明源碼和編譯器相處愉快真正要驗證的是數(shù)據(jù)訪問鏈路通不通。整個過程三件套每次都做不跳步。第一件剛Build完去輸出目錄看一眼.dcu文件的時間戳是不是當前時間。命令行里一行就能檢查ls -l --time-stylelong-iso *.dcu | tail -5看最后幾個文件的修改時間。如果顯示的是幾分鐘前、幾小時前說明控件包里的文件還是舊的Build可能沒生效比如命令行編譯時路徑指錯了。這個檢查能避免很多“我明明改了代碼為什么不生效”的玄學問題。第二件建一個最小工程只放一個TUniConnection和一張表單用第 3.3 節(jié)那段代碼連一次 SQLite確認Connect和ServerVersion都正常。不要一上來就連公司內(nèi)網(wǎng)的 Oracle 或生產(chǎn)庫——環(huán)境因素太多數(shù)據(jù)庫服務器不可達、賬號權限不對都會干擾判斷讓人分不清是控件問題還是網(wǎng)絡問題。第三件把編譯產(chǎn)物復制到另一臺干凈的機器上雙擊運行一次確認運行時依賴項尤其是各類數(shù)據(jù)庫客戶端庫都在。這一點很多開發(fā)者只在發(fā)版前才想起結果在上線現(xiàn)場翻車。我之前接過一個模擬項目X急著把報表模塊改成直連數(shù)據(jù)庫跳過最小驗證直接接入了某跨平臺系統(tǒng)的現(xiàn)有代碼結果連庫一直超時。排查了一個多小時才發(fā)現(xiàn)是 32 位客戶端庫被放進了 64 位進程的搜索路徑DLL 位數(shù)不匹配導致加載失敗——這類問題靠看代碼是看不出來的只有最小連接驗證能第一時間暴露它。從那以后我每次拿到帶日期戳的源碼包都會把“編譯時間戳檢查 SQLite 最小連接 干凈機器運行測試”完整走一遍再談集成。這套流程看起來多花十分鐘但比起后面盯著日志大海撈針值太多了。希望幫到你。本文還有配套的精品資源點擊獲取 UniDAC 10.3源碼版在Delphi 12與Lazarus下的編譯安裝與避坑指南
簡介這是一套面向 Delphi 12、Free Pascal Compiler 3.3.1 與 Lazarus 3.9.9 開發(fā)環(huán)境的 UniDAC 10.3 完整源代碼包目標用戶聚焦于對數(shù)據(jù)庫訪問層有定制需求或希望深入組件原理的 Delphi 開發(fā)者。壓縮包總計 2000 個文件核心為 1960 個 hpp 頭文件配合少量 cpp 源文件、sql 腳本、txt 說明、xml 配置及 html 文檔整體體積 231.35MB。目錄結構按功能劃分Source 存放可讀的組件實現(xiàn)Demos 提供可直接運行的示例程序Include 與 Lib 輔助編譯和最終部署Doc 與 History 分別收錄參考文檔和版本更新記錄DbToolsInterfaces 定義數(shù)據(jù)庫工具接口Http 補充網(wǎng)絡通信能力。目前已有 139 人瀏覽學習適合具備一定開發(fā)經(jīng)驗、需要快速掌握跨數(shù)據(jù)庫統(tǒng)一訪問方案或進行底層定制的學習者。通過安裝說明、示例程序與源碼解讀學習者不僅能系統(tǒng)理解連接管理、SQL 執(zhí)行與事務處理等核心機制還能在實際項目中集成或進行二次開發(fā)。1. 一份源碼版的 delphi 控件包拿到 UniDAC 10.3 先想清楚三條線Delphi 控件源碼包看多了之后我拿到 UniDAC 10.3 這份帶D12-fpc331-Laz399-20241005-ok后綴的資源第一反應不是雙擊安裝而是先把它當作一個待拆的工程來看。這個后綴含義很直白它能同時適配 Delphi 12、Free Pascal 3.3.1、Lazarus 3.99 三條編譯線。對只想裝個控件連數(shù)據(jù)庫的開發(fā)者來說源碼版看著勸退但對要維護跨平臺桌面程序、又不想被安裝包黑匣子綁架的人來說這份資源恰恰能把數(shù)據(jù)庫訪問層的編譯細節(jié)打開給你看。它適合動手派不適合只點下一步的人。下面是我拆包、編譯、踩坑的完整記錄。2. UniDAC 10.3 源碼包結構拆解先分清楚 Delphi 12 和 Lazarus 兩條編譯線2.1 目錄布局一份源碼包兩條編譯線拿到源碼包之后別急著打開 Delphi 12先用文件管理器把整個目錄結構過一遍。我一般會先看有沒有Source根目錄再看里面是否有Delphi12、Laz、FPC這類明顯按工具鏈劃分的子目錄。常見布局大致如下UniDACSource ├── Source │ ├── Core # 核心運行時單元 │ ├── Providers # 各家數(shù)據(jù)庫驅動實現(xiàn) │ ├── Delphi12 # Delphi 12 專用 dpk 工程 │ ├── Delphi10 # 老版本 Delphi 分支可忽略 │ └── Laz # Lazarus 的 lpk 包工程 ├── Lib │ ├── D12 # Delphi 12 編譯產(chǎn)物輸出 │ └── Laz # Lazarus 編譯產(chǎn)物輸出 ├── sqlite3.dll # 本地 SQLite 驅動庫按需放置 └── ReadMe.txt這份源碼包里的Source\Core和Source\Providers是兩個最關鍵的位置。Core放的是 UniDAC 的抽象層單元比如連接對象、命令對象、事務對象的基類定義Providers下則是各類數(shù)據(jù)庫的具體實現(xiàn)Oracle、SQL Server、MySQL、PostgreSQL、SQLite 各占一個目錄。目錄名里的fpc331和Laz399表示這套源碼同時帶了 Free Pascal 3.3.1 和 Lazarus 3.99 的工程文件不是只能給 Delphi 12 用。我通常會先看ReadMe.txt和Source\Delphi12下的.dpk文件數(shù)量。.dpk文件是 Delphi 的包工程文件一個控件包往往拆成運行時包和設計時包兩個甚至更多。如果Delphi12目錄下只有一個.dpk往往說明作者把運行時和設計時合并在一起了安裝會簡單些如果拆成多個比如dclUniDAC和UniDAC編譯順序就要注意這個坑后面會專門說。2.2 運行時包與設計時包的分工先厘清編譯順序UniDAC 這類控件在 Delphi 里安裝時背后涉及兩類包運行時包Runtime Package和設計時包Design-Time Package。運行時包是程序運行時要加載的里面是真正的業(yè)務邏輯單元比如TUniConnection、TUniQuery這些類的實現(xiàn)設計時包則是給 IDE 本身用的里面主要是組件注冊代碼負責讓控件出現(xiàn)在工具面板上并串聯(lián)屬性編輯器。這兩類包有嚴格的依賴順序必須先編譯運行時包并安裝它再編譯設計時包。因為設計時包源碼里uses了運行時包的單元編譯時需要能找到對應的.dcu或.bpl文件。順序反了最常見的報錯是Unit not found或者Cannot load package。從資源落地角度講我們下載這套源碼不是看它能不能裝上而是理解它背后這套依賴鏈出問題時才知道往哪查。我把這個順序總結成一句口訣先Build運行時再Install設計時。Build是編譯但不安裝Install是把包注冊進 IDE。順序錯了IDE 的組件面板上要么什么都不出現(xiàn)要么出現(xiàn)一堆帶問號的錯誤項。2.3 源碼版和安裝版怎么選邊界在哪里很多開發(fā)者的第一反應是向別人要一個別人裝好的安裝版雙擊下一步完事。但安裝版有個天然問題它往系統(tǒng)里塞了注冊表項、服務、全局路徑換臺機器重裝一遍或者換個 IDE 版本之前裝的控件就變成黑匣子出了問題很難查。源碼版的好處是每條編譯路徑都攤在你面前dpk文件里寫了哪些單元參與編譯條件編譯指令里定義了哪些版本分支全都能看到。但這不意味著源碼版適合所有場景。如果只是在固定的 Delphi 12 環(huán)境里做一個小工具安裝版確實更省事如果像這個資源標題一樣明確帶了fpc331和Laz399說明發(fā)布者的意圖就是讓你在多個 IDE 生態(tài)里復用同一套代碼。這種情況下源碼版的優(yōu)勢就出來了同一個TUniConnection單元Delphi 12 下編譯一次拿到 Lazarus 3.99 里用.lpk工程再編譯一次業(yè)務代碼不用動。我個人的習慣是只要是跨平臺項目一律用源碼版并且把源碼包放到固定目錄比如D:\Libs\UniDAC不要放在項目目錄里。這樣多個工程可以共用一份編譯好的.dcu不會出現(xiàn)每個工程都復制一份源碼導致版本漂移的問題。3. 在 Delphi 12 里把 UniDAC 編譯安裝起來從 Library Path 到最小連接驗證3.1 編譯前的庫路徑與條件編譯在 Delphi 12 里編譯 UniDAC 之前第一步是把源碼目錄加到 IDE 的搜索路徑里。打開Tools Options Delphi Options Library在Library Path里把Source\Core和Source\Providers加進去。注意這里不要加Source\Delphi12因為那個目錄里放的是.dpk工程文件不是單元源碼加了反而會讓 IDE 在啟動時嘗試加載多余文件拖慢速度。這套源碼在 Delphi 12 下編譯時會走條件編譯分支。源碼里通常會有類似下面的判斷{$IF Defined(VER360)} // Delphi 12 Athens 對應的編譯器版本 {$DEFINE UNIDAC_D12} {$ENDIF}這個代碼塊的作用是在編譯期根據(jù) Delphi 編譯器版本號決定是否定義UNIDAC_D12這個編譯符號。實際版本號取決于你裝的 Delphi 12 更新包打開 IDE 后按CtrlAltE或查看About窗口里的編譯器版本就能確認對應值。如果你在源碼里看到了類似的IF Defined指令不要手欠去改它默認分支通常已經(jīng)覆蓋了當前版本。加完路徑后先做一次干凈編譯檢查打開Project Manager看左側樹里有沒有報紅叉的節(jié)點。如果一切正常再進行包的編譯。這一步我習慣單獨花十分鐘做不著急點Build因為路徑配錯了后面的報錯會連成一片很難定位根因。3.2 編譯運行時包與設計時包的正確順序把源碼包加載進 Delphi 12 的方式很簡單File Open定位到Source\Delphi12目錄打開里面的.dpk文件。打開后Project Manager會把它當作一個包工程顯示。這時先看包的名字以dcl開頭的通常是設計時包不帶dcl的是運行時包。如果兩個文件都有先處理不帶dcl的那個。我一般會用命令行方式編譯界面操作雖然直觀但命令行能穩(wěn)定復現(xiàn)步驟。打開 Delphi 自帶的命令行環(huán)境進入源碼目錄執(zhí)行類似下面的命令dcc32.exe -B -Q -DD12 UniDAC.dpk dcc32.exe -B -Q -DD12 -LU dclUniDAC.dpk第一行-B表示全量重新編譯-Q靜默模式減少輸出干擾-DD12是定義編譯符號對應源碼里D12分支第二行里的-LU表示編譯設計時包時鏈接運行時包。實際執(zhí)行時.dpk文件名需要以源碼目錄里的實際文件名為準不要照抄。如果你不習慣命令行也可以在 IDE 里操作先右鍵運行時包選擇Build再右鍵設計時包選擇Build最后對設計時包選擇Install。這里有個容易誤解的細節(jié)Build和Compile不是一回事。Build會重新編譯所有單元不管有沒有變化Compile只編譯有改動的。從網(wǎng)上下載的源碼包目錄里可能殘留著舊.dcu文件所以第一次必須用Build否則可能出現(xiàn)編譯“成功”但實際跑的還是舊代碼的情況。3.3 用 TUniConnection 驗證安裝結果編譯安裝完組件面板上出現(xiàn)UniDAC選項卡之后不要急著往項目里拖控件。先建一個最小的測試工程用代碼方式驗證安裝結果。新建一個VCL Forms Application放一個按鈕和一個Memo在按鈕事件里寫uses Uni, SQLiteUniProvider, UniProvider; procedure TForm1.Button1Click(Sender: TObject); var Conn: TUniConnection; begin Conn : TUniConnection.Create(nil); try Conn.ProviderName : SQLite; Conn.Database : C:\Temp\test.db; Conn.Connect; Memo1.Lines.Add(連接成功服務端版本: Conn.ServerVersion); finally Conn.Free; end; end;這段代碼的邏輯是創(chuàng)建TUniConnection實例設置ProviderName為SQLite指定數(shù)據(jù)庫文件路徑然后調用Connect建立連接。ServerVersion是連接成功后從驅動層取回的版本字符串能取到就說明整條調用鏈是通的。uses里必須在Uni之后顯式引用SQLiteUniProvider這一點很關鍵——UniDAC 默認不會把所有數(shù)據(jù)庫驅動都鏈接進來少了這一行運行時大概率報Provider not found。跑這個測試之前記得把sqlite3.dll放到exe所在目錄。源碼包自帶的那個sqlite3.dll通常在包的根目錄或Lib目錄下。如果忘了放Connect會直接報錯后面避坑章節(jié)會專門展開。4. 避坑指南UniDAC 在 D12 / FPC / Lazarus 混編時最容易翻車的五個點4.1 運行時包編譯通過設計時包報 Unit not found現(xiàn)象先編譯了運行時包再編譯設計時包結果 IDE 彈窗提示找不到某個.dcu文件。按下F12看錯誤面板報錯的行是設計時包某個單元的uses語句。原因運行時包雖然編譯成功了但.dcu輸出目錄沒有加入到 Delphi 的Library Path里。Build只是生成了文件IDE 在編譯設計時包時還不知道該去哪個路徑找這些.dcu。解決打開Tools Options Delphi Options Library把運行時包設置的Output directory通常在包工程的Project Options里配置加到Library Path?；蛘吒直┑淖龇ò堰\行時包安裝到 IDE 里右鍵Install讓 IDE 自己記錄它的輸出路徑。從那以后我遇到Unit not found第一反應從“代碼寫錯”改成“路徑?jīng)]指對”排查速度快了很多。4.2 連接 SQLite 時報錯無法加載 sqlite3.dll現(xiàn)象編譯、安裝、拖控件都沒問題運行測試工程點按鈕后彈出Could not load sqlite3.dll或類似提示程序在Connect這行中斷。原因這個報錯非常經(jīng)典。UniDAC 的 SQLite 驅動只是一個包裝層真正干活的是 SQLite 官方的sqlite3.dll。源碼包里雖然帶了這份文件但它不會自動復制到你的exe輸出目錄。Delphi 編譯產(chǎn)物和這個 DLL 分處兩個目錄運行時按當前工作目錄找 DLL自然找不到。解決把sqlite3.dll手動復制到exe所在目錄或者放到C:\Windows\System32不推薦污染系統(tǒng)目錄。另一個細節(jié)如果你的工程編譯成 64 位sqlite3.dll也必須是 64 位版本32 位 DLL 在 64 位進程里加載會直接報錯這個坑在換平臺時特別容易踩。4.3 Lazarus 3.99 下編譯 lpk 報錯FPC 3.3.1 分支對不上現(xiàn)象在 Lazarus 3.99 里打開Source\Laz下的.lpk文件點編譯報錯信息指向 FPC 運行時庫的某個單元說簽名不一致或找不到某個聲明。原因這個資源標題里寫的fpc331是 Free Pascal 的 trunk 分支不是穩(wěn)定版Laz399同樣接近開發(fā)主線。trunk 分支的運行時庫經(jīng)常改接口今天能編譯的代碼明天更新 FPC 后可能就報錯。如果 Lazarus 自帶的 FPC 版本和源碼包作者當時用的不完全一致就會撞上這類問題。解決先把 FPC 編譯器路徑指到資源對應的fpc331版本在 Lazarus 的Tools Options Files Compiler Path里確認。如果公司項目里還跑著舊版 Lazarus我的建議是給源碼包單獨準備一套 FPC Lazarus 環(huán)境不要和老項目混用。用Lazarus目錄下的lazbuild.exe命令行編譯可以更快定位問題lazbuild.exe --add-package Source\Laz\UniDAC.lpk lazbuild.exe --build-filetest.lpr--add-package的作用是把lpk包注冊進 Lazarus 的包列表--build-file再對實際工程做編譯這樣報錯時能看到是包本身的問題還是工程引用的問題。4.4 源碼路徑帶中文或空格編譯到一半 IDE 卡死現(xiàn)象把源碼包解壓到D:\下載\UniDAC 10.3\這種帶中文和空格的目錄編譯工程時 IDE 偶發(fā)卡死或報出一些亂碼路徑的錯誤。原因老一批控件源碼在內(nèi)部拼接路徑時還在用AnsiString或char指針中文路徑在 Delph 的默認代碼頁下會編碼錯亂空格則會讓某些內(nèi)部命令行工具把路徑拆成兩段。解決源碼包解壓后直接放在純英文無空格的路徑比如D:\Libs\UniDAC_Source。這個習慣最好在所有第三方控件上統(tǒng)一執(zhí)行不只是 UniDAC。Delphi 自身的Library Path支持帶空格的路徑但第三方控件內(nèi)部處理不一定會考慮到這一點沒必要在這種地方賭運氣。4.5 編譯一切正常運行時提示 Provider not found現(xiàn)象測試工程編譯、運行都正常連接MySQL或PostgreSQL時運行時報Provider not found或Unknown provider。原因和 3.3 里說的一樣UniDAC 的驅動是延遲加載的。源碼包把各種 Provider 都放在Source\Providers里但編譯器不會把用不到的單元鏈接進程序。如果代碼里只uses Uni那程序里就真沒有 MySQL 或 PostgreSQL 的驅動實現(xiàn)。解決在工程主單元的uses里顯式引用對應的 Provider 單元uses Uni, MySQLUniProvider, // 使用 MySQL 時 PostgreSQLUniProvider, // 使用 PostgreSQL 時 SQLiteUniProvider; // 使用 SQLite 時這段代碼的邏輯是告訴編譯器這幾個 Provider 單元必須參與鏈接。這樣TUniConnection在運行時才能根據(jù)ProviderName找到對應實現(xiàn)。從源碼包里也能看到這些單元名Source\Providers目錄下每個子目錄對應一個 Provider單元名稱通常就是數(shù)據(jù)庫名 UniProvider的格式。5. 編譯完先別急著集成驗證最小連接的三個習慣第 4 章五個坑都避開之后編譯安裝這一關算是過了但在把它集成進真實項目之前我強烈建議補一道驗證。不是驗證控件能不能編譯——編譯通過只說明源碼和編譯器相處愉快真正要驗證的是數(shù)據(jù)訪問鏈路通不通。整個過程三件套每次都做不跳步。第一件剛Build完去輸出目錄看一眼.dcu文件的時間戳是不是當前時間。命令行里一行就能檢查ls -l --time-stylelong-iso *.dcu | tail -5看最后幾個文件的修改時間。如果顯示的是幾分鐘前、幾小時前說明控件包里的文件還是舊的Build可能沒生效比如命令行編譯時路徑指錯了。這個檢查能避免很多“我明明改了代碼為什么不生效”的玄學問題。第二件建一個最小工程只放一個TUniConnection和一張表單用第 3.3 節(jié)那段代碼連一次 SQLite確認Connect和ServerVersion都正常。不要一上來就連公司內(nèi)網(wǎng)的 Oracle 或生產(chǎn)庫——環(huán)境因素太多數(shù)據(jù)庫服務器不可達、賬號權限不對都會干擾判斷讓人分不清是控件問題還是網(wǎng)絡問題。第三件把編譯產(chǎn)物復制到另一臺干凈的機器上雙擊運行一次確認運行時依賴項尤其是各類數(shù)據(jù)庫客戶端庫都在。這一點很多開發(fā)者只在發(fā)版前才想起結果在上線現(xiàn)場翻車。我之前接過一個模擬項目X急著把報表模塊改成直連數(shù)據(jù)庫跳過最小驗證直接接入了某跨平臺系統(tǒng)的現(xiàn)有代碼結果連庫一直超時。排查了一個多小時才發(fā)現(xiàn)是 32 位客戶端庫被放進了 64 位進程的搜索路徑DLL 位數(shù)不匹配導致加載失敗——這類問題靠看代碼是看不出來的只有最小連接驗證能第一時間暴露它。從那以后我每次拿到帶日期戳的源碼包都會把“編譯時間戳檢查 SQLite 最小連接 干凈機器運行測試”完整走一遍再談集成。這套流程看起來多花十分鐘但比起后面盯著日志大海撈針值太多了。希望幫到你。本文還有配套的精品資源點擊獲取