小小大大學

 很多人在 Notion 建立排程表、上傳計畫、學習打卡表時，會遇到一個常見問題： 我想讓日期像 Excel 一樣，每一列自動加一天，可以嗎？ 例如： 2026/02/01 2026/02/02 2026/02/03 2026/02/04 在 Excel 裡，只要往下拉就可以自動遞增日期。 但在 Notion 裡，資料庫不是傳統試算表，所以不能直接用「上一格 + 1 天」的方式自動填入。 不過不用擔心，我們可以用 Number 欄位 + Formula 欄位 ，做出非常接近 Excel 自動增加日期的效果。 一、Notion 為什麼不能直接像 Excel 一樣往下拉日期？ Notion 的資料庫每一列比較像一筆獨立資料，而不是 Excel 那種連續格子。 所以 Notion 目前不能直接做到： 下一列日期 = 上一列日期 + 1 天 也就是說，Notion 公式通常是根據「同一列的欄位」計算，而不是去讀上一列的資料。 因此我們要改用另一種思路： 起始日期 + 第幾天 = 自動日期 二、最推薦做法：起始日期 + 天數編號 假設你的起始日期是： 2026/02/01 你可以新增一個數字欄位，叫做： 天數編號 然後填入： 0 1 2 3 4 5 接著用公式自動算出日期。 三、Notion 欄位設計 建議建立三個欄位： 欄位名稱 欄位類型 說明 起始日期 Date 第一筆日期 天數編號 Number 第幾天 自動日期 Formula 自動產生日...

📖 前言：為什麼需要「日期自動生成」？ 在實務工作中（像是報表、排程、金融或製造業系統），常會遇到這種需求： 👉「日期不是每天都有，而是依照某種規律跳動」 例如： 有時隔一天 有時隔兩天 而且這個規律是 固定循環的 手動打 Excel 非常容易出錯，也很浪費時間，所以我們用 Python 來解決。 🧠 問題拆解（用最白話方式講） 我們的需求是： ✅ 起始日期 2026/01/26 ✅ 日期不是每天增加，而是照這個規律： +1 天 → +2 天 → +2 天 → +2 天 → 然後重複 👉 這種就叫做「循環規律」 🔁 規律視覺化（幫你更好理解） 次數 增加天數 日期 1 起始 2026/01/26 2 +1 2026/01/27 3 +2 2026/01/29 4 +2 2026/01/31 5 +2 2026/02/02 6 +1 2026/02/03 ... 重複 ... ⚙️ 解法概念（工程師思維） 我們會做三件事： 設定起始日期 設定規律陣列（pattern） 用迴圈一直加日期，直到年底 🧪 Python實作 import pandas as pd from datetime import datetime, timedelta # 1️⃣ 初始設定 begin_day = datetime(2026, 1, 26) limit_day = datetime(2026, 12, 31) # 2️⃣ 規律設定（循環使用） step_rules = [1, 2, 2, 2] # 3️⃣ 儲存結果 result_list = [] current ...

🔍 一、為什麼 Automation 排程會「突然失敗」？ 很多人在使用 Spotfire 或類似報表系統時，都會遇到一個問題： 👉 排程有時候成功，有時候失敗（而且沒有明顯原因） 這種「不穩定」其實比直接壞掉更難處理。 如果你是工程師，第一直覺可能會是： 是不是程式寫錯了？ 但實務上， 80% 的排程問題，其實不是程式問題，而是「環境問題」 。 🧠 二、先用白話理解整個系統在做什麼 想像一個流程： 排程觸發 → Server → 資料庫 → 執行節點 → 回傳結果 可以想成： Server = 大腦 🧠 Database = 記憶 📚 Node Manager = 工人 👷 只要其中一個環節卡住，整個流程就會失敗。 🚨 三、實際案例：兩個最常見的致命問題 在實際 log 分析中，最常看到這兩種錯誤： ❌ 問題一：資料庫連線拿不到（DB Connection Timeout） 📍 現象 系統在執行排程時，突然無法連線資料庫。 📍 白話解釋 就像這樣： 👉 你要查資料 👉 但資料庫說：「我現在很忙，你等一下」 👉 等太久 → 超時 → 失敗 ❌ 📍 錯誤範例 Error: Unable to acquire database connection Reason: Connection pool exhausted Timeout: 10 seconds 📍 可能原因 同時太多人使用資料庫 連線池設定太小 有 SQL 卡住（lock / blocking） 網路延遲 ❌ 問題二：SSL 憑證驗證失敗（Node Manager 斷線） 📍 現象 執行報表的節點（Node）無法跟 Server 溝通。 📍 白話解釋 就像： 👉 Node 說：「我要確認你是不是合法的 Server」 👉 但它無法驗證憑證 👉 所以直接拒絕連線 ❌ 📍 錯誤範例 Error: Secure connection failed Cause: Certificate validation could not be completed Detai...

 很多工程師都會遇到這種情況： 👉 畫面顯示「無資料」 👉 API 呼叫成功（HTTP 200） 👉 Swagger 測試也正常 👉 但 Response 卻是： [] （空陣列） 最讓人困惑的是： 👉 資料庫明明有資料！ 這篇文章會用「白話＋工程師角度」帶你一步步找出問題，並教你怎麼從根本解決。 🚨 問題核心：為什麼 API 會回 [] ？ 在多數後端程式中，回傳空陣列通常只會發生在這兩種情況： 情況一：查詢條件找不到資料 也就是： 👉 你查的條件「沒有對應資料」 情況二：程式主動把資料擋掉（設計邏輯問題） 例如： 如果日期清單是空的 → 直接回 [] 👉 這種設計會導致： 即使「主資料有」，但「輔助資料沒有」 👉 API 還是回空 🧩 常見資料流程（簡化理解） 很多報表 API 其實做兩件事： ① 先拿「日期清單」 從某張參數表抓日期 ② 再拿「主資料」 從另一張表抓數據 👉 最後組成結果回給前端 ❗ 致命設計錯誤（超常見） 很多程式會寫成： 👉 如果日期清單是空 → 直接回空資料 但問題是： 👉 日期表和主資料表「不是一定同步」 🧪 實際排查方法（Oracle SQL） 以下是你可以在資料庫直接驗證的步驟。 ✅ Step 1：確認主資料是否存在 SELECT COUNT(*) FROM 主要資料表 WHERE 版本欄位 = '你的版本'; 結果判斷： 0 → 有資料 ✅ = 0 → 根本沒資料 ❌ ✅ Step 2：檢查「版本字串」是否完全一致 SELECT 版本欄位, LENGTH(版本欄位) FROM 主要資料表 WHERE 版本欄位 LIKE '關鍵字%'; 常見問題： 多空白 少一段（例如 .01） 全形 / 半形不同 👉 這種問題超常見！ ✅ Step 3：檢查日期清單是否抓得到 SELECT COUNT(DISTINCT 日期欄位) FROM 日期來源表 WHERE 版本欄位 LIKE '%關鍵字%' AND 日期欄位 IS NOT NULL; 👉 如果這裡是 0： ✔ API 會直接回 [] ❌ 就算主資料有...

🚨 問題現象：為什麼系統 10 月後完全沒資料？ 在實務專案中，你可能會遇到一種情況： 👉 系統「某個時間點之後完全沒有資料載入」 👉 排程看起來正常，但資料就是沒有進來 這種問題非常常見，而且 很容易被誤判成資料問題或程式邏輯錯誤 。 但其實，真正原因可能是： 💥 JVM（Java 虛擬機）記憶體爆掉，程式直接被系統強制終止 🔍 真正原因解析：JVM 記憶體不足（不是你想的那麼簡單） 從 log 觀察可以看到類似訊息： Native memory allocation failed Out of memory condition GC region allocation error 這代表什麼？ 👉 JVM 嘗試向系統申請記憶體失敗 👉 作業系統拒絕分配 👉 JVM 被迫中止（直接 crash） ⚠️ 重點：不是只有「Heap 記憶體」會影響 很多人以為： JVM 記憶體 = -Xmx（最大 Heap） 但其實錯了 ❗ JVM 使用的記憶體包含： Heap（物件資料） Thread Stack（執行緒） Code Cache（JIT 編譯） Direct Memory（NIO） GC 空間 Class Metadata 👉 所以實際使用量通常是： 實際記憶體 ≈ Heap + 額外30%~50% 📉 為什麼 10 月之後才爆？ 這種情況通常是： ① 資料量變大 批次檔案變多 單一檔案變大 ② 系統記憶體壓力增加 同機器多服務 RAM 被吃掉 虛擬記憶體不足 ③ Windows Pagefile（虛擬記憶體）問題 這是 最關鍵但最容易忽略的點 ： 👉 JVM 會用到「系統承諾記憶體（Commit Memory）」 如果 Pagefile 太小或關閉： 💥 就會出現記憶體申請失敗 🧨 另一個隱藏問題：資料轉換錯誤（NullPointerException） 在資料處理流程中，還可能看到這類錯誤： Null reference encountered Data field missing 這代表： ...