NotesUIDatabase：攔下一個刪除的唯一地方

在 Notes client 裡，使用者可以從任何 view、用 Delete 鍵、用剪下、或拖進垃圾桶刪掉一份文件 —— 你沒辦法一條路一條路去守。NotesUIDatabase 是看得見全部路徑的單一 chokepoint：它的 QueryDocumentDelete 事件在任何東西被標記刪除之前，整個資料庫觸發一次。一篇前端資料庫類別的實測報告 —— 通往後端的 Database 橋、刪除／封存事件，以及你掛在「那個攔得住每條路的事件」上的軟刪除守衛。

Save(True, False) 還是 Save(False, True)：決定誰的資料會不見的兩個布林值

兩個程序動到同一份文件 —— 一個 web agent 和一個開著表單的使用者，或一個排程 agent 和一個 replica。一邊的儲存贏，另一邊的編輯要嘛消失、要嘛變成一份沒人發現的 $Conflict。發生哪一種，完全由你傳給 NotesDocument.Save 的那兩個布林值決定。一篇關於 force 與 createResponse 的實測報告：last-write-wins 對上 replicator 產生的衝突文件、為什麼 Save(True, False) 會靜默丟資料、以及怎麼刻意地選對。

NotesUIView：唯一知道使用者選了什麼的類別

view 上的動作按鈕理應對使用者反白的那幾列作用 —— 但後端的 NotesView 根本沒有「選取」這個概念。那道缺口，正是 NotesUIView 填的。一篇前端 view 類別的實測報告：它的 Documents 屬性（活的選取狀態）、通往後端 View 的橋、你用來攔截使用者的 QueryOpenDocument／QueryClose 事件，以及那條把這一切擋在 web 與 agent 之外的硬邊界。

你永遠不會 new 出來的 NotesDOM 節點：唯讀的 DTD 角落

NotesDOM 實作了完整的 W3C 節點模型，這代表有四種節點型別存在於多數 XML 開發者從不碰的 DTD 角落：DocumentType、Entity、EntityReference、Notation。一份簡短地圖 —— 它們是什麼、哪一個你真的能建立（EntityReference）、哪些是已解析 DTD 的唯讀反映、以及為什麼在 2026 年你多數時候可以直接走過它們，外加那個「知道它們存在能省下一個下午」的情境。

NotesDOM 你略過的那些節點 —— 直到一次 round-trip 把註解吃掉

你用 NotesDOMParser 建好了處理 element 與 text 節點的流程。然後來了一份帶註解、CDATA 區塊、processing instruction 的 XML，你改一個值、序列化回去 —— 註解和 PI 不見了，CDATA 變成被跳脫的純文字。一篇 NotesDOM 節點家族長尾的實測報告：NodeList 那個 1-based 的 GetItem（不是 W3C 的 0-based item()）、用來批次插入的 DocumentFragment，以及你得自己建立、才留得住的 CDATA／註解／processing instruction 節點。

Domino Web View 翻頁的真相：Start 不是流水號，是階層座標

「我以為 Start=31 就是第 31 列，然後我錯了。」一篇 classic view ?OpenView Start 參數的除錯實測報告：純數字跳到第 N 個最上層分類、像 1.1.1.1.6 的點號值是階層座標、末段會 clamp 但中段不會、而你沒辦法用一個 URL 跳到絕對最後一頁。外加三個實用應用 —— 分類內序號、@DocNumber("")（含必須單獨使用的地雷）、以及用 ReadViewEntries 做麵包屑。

你的 Domino view 表頭為什麼永遠歪一格：passthrough HTML 黑魔法考古

接手一個老 classic-web Domino view，你常會發現直欄標題整體往右偏一格 —— 而且沒人知道為什麼。一篇實測報告，挖出藏在二十年前 view 設計裡的 passthrough HTML 把戲：直欄值與標題裡的方括號 HTML、間隔欄、每列 checkbox，以及真正的元兇 —— 一個故意不閉合的 <input 標籤吞掉 </td><td> 欄界線、把兩個直欄合併成一格，讓它之後的每個表頭都往右偏。

DQL 跳「Domino Query 執行時錯誤」怎麼辦：三層診斷階梯

一個 DQL 查詢失敗，你看到「Domino Query 執行時錯誤:」後面接一大串文字。一篇讀懂這個訊息的實測報告：你在 Err 裡找到的 4854 對診斷毫無用處（每個 DQL 失敗都回它），答案永遠在「詳細原因」那一行。涵蓋四段訊息結構、三層階梯（catalog / view 沒建 / partial TIMEDATE）、讓查詢時好時壞的 design catalog 半殘、以及「0 筆且無錯誤」的排查清單。

DQL view 日期直欄查詢：型別與時區怎麼無聲吃掉你的結果（三個成因）

「直欄轉成日期反而有些抓得到有些沒抓到，蠻怪的。」一篇實測報告：一個 DQL view 直欄日期查詢結果不一致，拆開來發現有三個獨立成因。DQL 從不自動轉型（所以直欄的輸出型別要跟查詢詞相符）、底層欄位存了文字與日期混型、而 @dt 不帶時區位移就是 UTC——它會在不改變總筆數的情況下弄壞邊界文件。兩個解法皆實測 6/6 全中。