小小大大學

  前言： 為什麼「明明昨天還能跑的報表，今天突然就壞了？」 如果你有用過 Tibco Spotfire ，你一定遇過這種情況： 👉 按下按鈕 👉 準備匯出報表 👉 系統突然跳出一整串看不懂的錯誤  👉 裡面還有英文、程式碼、Exception 這篇文章會用 「完全不懂程式的人也能理解」 的方式，告訴你： DXP 到底出了什麼問題 為什麼這不是資料錯誤 為什麼工程師會說「系統正在忙」 要怎麼設計，才不會再出現同樣的錯誤 一、先講結論：這不是你操作錯，也不是資料壞掉 這類 Spotfire DXP 錯誤， 99% 不是資料問題 ，而是： ❗ 系統正在執行某個工作時，又被要求「同時做另一件事」 就像這種生活情境： 你正在講電話 對方還沒掛 另一通電話又硬要插進來 👉 系統直接當機 二、用白話說：Spotfire 為什麼會拒絕你？ 我們先把 Spotfire 想成一個「很守規矩的助理」 一次只做一件事 做事時，不准被打斷 事情做完，才接受下一個指令 但問題來了👇 你下的指令其實是這樣的： 「請幫我準備資料」 「順便把報表存成 PDF」 「啊對了，存的時候幫我改一下內容」 對人類來說很合理 但對 Spotfire 來說是： ❌「我現在正在做第 1 件 ❌ 你不能同時叫我做第 2、3 件」 三、為什麼錯誤訊息會這麼可怕？ 你可能看到類似這種畫面： 系統錯誤 Invalid operation Begin transaction failed  Execution state conflict 工程師實際看到的是什麼？ 工程師翻譯後的意思只有一句話： 「你在我還沒忙完的時候，又叫我開始另一個工作」 四、最常見的「地雷設計」有哪些？ 以下是 非工程師最容易踩到的情境 👇 🚨 地雷 1：按鈕一按，就做「太多事情」 例如一個按鈕同時做： 更新資料 重新整理畫面 匯出報表 👉 對系統來說，這是「同時三個命令」 🚨 地雷 2：報表還沒準備好，就強制匯出 想像成： 文件還沒存好 就叫印表機印 Spotfire 會直接拒絕。 🚨 地雷 3：自動化排程...

📌 前言：我只是點個程式，為什麼報表都跑到 D 槽去了？ 如果你在工作中用到 TIBCO Spotfire 來自動產生報表，可能會遇過一個情況： 報表的 PDF 或 CSV 雖然會自動產出，但你永遠搞不清它跑去哪了！ 其實，報表的輸出位置是寫在一段「程式腳本」裡的。就算你不會寫程式，看完這篇也能看懂並自行修改儲存位置，讓報表乖乖存到你想要的資料夾！ 🛠️ 報表儲存路徑到底在哪裡設定？ ✅ 關鍵程式碼片段 Spotfire 會透過腳本判斷今天是什麼日子，來決定要把報表存在哪裡。例如： from datetime import datetime from os import makedirs from os.path import exists today = datetime.today() if today.weekday() == 2 : # 週三 save_folder = f"D:/Reports/Weekly/ {today.strftime( '%Y-%m-%d' )}" elif today.day == 5 : # 每月 5 號 save_folder = f"D:/Reports/Monthly/ {today.strftime( '%Y-%m-%d' )}" 這段的意思是： 每週三：報表會儲存在 D:/Reports/Weekly/2026-01-06/ 每月 5 號：儲存在 D:/Reports/Monthly/2026-01-05/ 這樣方便你回頭查報表，不會一團亂！ 📁 如果要改儲存位置，要改哪裡？ 只要找到上面 save_folder = 的地方，把 D:/Reports/... 換成你想要的資料夾即可！ 例如： save_folder = f"Z:/部門報表備份/ {today.strftime( '%Y%m%d' )}" 這樣就會儲存在： Z:\部門報表...

前言：這個錯誤，90% 的人都修錯方向 如果你在 TIBCO Spotfire 裡，按下查詢（Query）後看到這樣的錯誤： Could not execute script: The column 'XXX' does not exist in the collection 你很可能會直覺認為： 「是不是 SQL 沒寫好？」 「是不是欄位名稱拼錯？」 「是不是資料庫沒有這個欄位？」 但事實是：這個錯誤大多不是 SQL 的問題，而是「資料表之間欄位定義不一致」造成的。 本文會用 完全不需要懂 Spotfire、也不需要懂程式 的方式，帶你一步一步理解： 👉 為什麼你明明「已經加了欄位」，Spotfire 卻還是說「找不到欄位」。 一、先用生活比喻，理解 Spotfire 在做什麼 想像你在做一份報表，就像在做一張 Excel 表格。 Spotfire 裡，其實同時存在三個角色： 角色 白話說明 資料來源 像是資料庫或查詢結果 資料表（Data Table） 匯入後存在 Spotfire 裡的一張表 畫面表格（Table Visual） 螢幕上看到的那個表格 關鍵重點：畫面上的表格，不一定使用你「剛剛查詢的那張資料表」。 二、問題的真正原因（核心觀念） ❌ 常見誤解 「我 SQL 已經加了這個欄位，為什麼畫...

前言： 「我明明在資料庫查不到，為什麼系統畫面卻顯示有？」 這是一個 幾乎所有工程師都一定會遇到 、而且常常讓人懷疑人生的問題。 ❓「資料庫明明沒有這筆資料， ❓ 為什麼系統畫面卻顯示得好好的？」 這篇文章會用 完全不需要程式背景 的方式， 一步一步帶你理解： 為什麼「你看到的畫面」不一定等於「資料庫現在的資料」 常見造成誤判的 5 大原因 工程師實務上如何快速定位問題 一、先講結論（給沒時間的人） 👉 99% 的情況不是資料庫錯，而是「你查的不是同一件事」 最常見的原因包括： 系統畫面與你手動查詢的「條件不一樣」 系統其實連到「不同資料庫或不同環境」 系統畫面顯示的是「快取的舊資料」 欄位是「系統自己組合出來的」，不是資料庫原始欄位 畫面兩個欄位「看起來一樣」，其實是同一個來源 接下來我們一個一個說清楚。 二、為什麼「畫面看到的資料」不一定是資料庫原始資料？ 🧠 用生活比喻來理解 想像你在看 手機銀行 App ： 你看到的是「帳戶餘額」 但實際上 App 可能是： 5 分鐘前同步的 來自備用資料庫 經過系統重新計算後的結果 👉 畫面 ≠ 即時資料庫 企業系統（特別是報表、BI、分析系統）幾乎都這樣設計。 三、常見誤會 1：你查的條件，跟畫面根本不是同一批資料 ❌ 新手最常犯的錯 「我用 A 條件查資料庫， 但畫面用的是 B 條件， 然後說資料不一致。」 👨‍💻 工程師會怎麼想？ 工程師一定會先確認： 產品代碼是否相同？ 製程階段是否相同？ 供應商是否相...

前言：為什麼「終止 bat」這件事很重要？ 在許多公司環境中，Windows 的 批次檔（.bat） 常被用來： 自動執行資料處理 定時跑程式（搭配工作排程） 串接多個工具一次完成工作 但只要其中一個步驟出問題，整支批次檔就可能： 卡住不動 錯誤卻繼續往下跑 背景一直吃資源卻沒人發現 👉 對完全不懂程式的人來說，最常見的困擾就是： 「這個黑色視窗怎麼關都關不掉？」 「它到底有沒有跑完？」  「出錯時可以自己停下來嗎？」 這篇文章，會用 白話 + 工程師實務 一次講清楚。 什麼是 .bat？可以把它想成「自動照流程做事的清單」 你可以把 .bat 想成一張「 電腦照著做的 SOP 清單 」： 先做事情 A 再做事情 B 接著做事情 C 全部做完就結束 每一行都是一個「指令」，電腦會 一行一行照順序做 。 為什麼 bat 會「跑不完」或「停不下來」？ 常見原因包括： 某個步驟在等資料，一直等不到 外部程式卡死但 bat 不知道 沒有告訴 bat：「出錯就要停」 結果就會變成： bat：我還在跑 人：我不知道它在幹嘛 😰 第一種終止方式：人工中斷（任何人都能用） 方法：鍵盤直接中斷 只要看到黑色視窗在跑，按下： Ctrl + C 畫面通常會出現類似： 是否要終止批次工作？ ( Y /N) 輸入 Y ，整個流程就會停止。 適合什麼時候？ 手動測試 發現跑錯 臨時要停 📌 缺點： 不夠安全 不適合自動化或工作排程 第二種方式：讓 bat「自己知道該停」（工程師最常用） 這種方式是 ...

內容 一、你看到的現象其實很典型：BIN 不見、(Empty) 出現、0.00 很多、選兩個 Lot 卻只剩一個 很多人第一次在 Spotfire 做 Yield / BIN 報表會遇到類似狀況： Yield Summary 表格應該要有 BIN1、BIN5、BIN36…，結果完全沒出現 表格或 Pivot 後的欄位出現 (Empty) BIN 欄位很多都顯示 0.00 ，看起來像「資料明明篩掉了 0，怎麼還是 0？」 明明選了兩筆（兩個 Lot），結果最後只剩一筆出現在 Yield Summary 這些問題看似四散，但本質都可以用「資料處理管線」的概念一次理解。 二、先用最簡單的比喻：Spotfire 就像一台「多段加工機」 你可以把整個流程想成： 資料庫（SQL） ：把原料（資料）運進來 Spotfire 的 Join/Pivot ：把原料組裝成你要的形狀 視覺化（Table/Chart） ：把結果畫成表格與圖表 互動（Marking/Filtering） ：你點了圖，其他視覺會跟著變 只要其中一段「加工」做錯，就會出現你看到的怪狀況。 三、最重要的核心：為什麼會出現 (Empty)？ Spotfire 的 Pivot 常見邏輯是： 你指定「分類欄位」當作 Pivot 後的欄名來源 如果那個分類欄位是空的（Null/空字串），Spotfire 就會把它統一歸類成 (Empty) ✅ 直覺理解 你想要欄位叫：BIN1、BIN2、BIN36 但你用來命名的那個欄位是空的 Spotfire 只好產生一個叫 (Empty) ...

  前言： 「資料明明存在，為什麼畫面卻是空的？」 這是一個 所有做過資料分析、BI 報表、或資料視覺化系統的人一定都遇過的問題 ： 👉 同一份資料 👉 同一個操作流程 👉 有時候畫面正常  👉 有時候卻「完全沒有資料」 而且最可怕的是： 沒有錯誤訊息 沒有 Exception 甚至 Debug log 看起來「一切正常」 這篇文章會帶你理解： 為什麼這種問題會發生，以及專業工程師是怎麼把它抓出來的。 一、先把名詞講清楚（給完全沒背景的人） 什麼是「Bin」？ 在很多測試或分類系統中，我們會把結果分成不同類別，例如： 類別編號 意義 Bin 1 通過 Bin 5 輕微異常 Bin 19 嚴重異常 工程師習慣把這些稱為 Bin（分類桶） 。 那為什麼會「沒有 Bin」？ 因為在一個完整系統中， 同一個 Bin，會用「不同方式表示」 。 舉例來說，下面這些其實「人類看起來一樣」，但 電腦完全不覺得一樣 ： 人類理解 系統實際字串 Bin 1 "1" Bin 1 "BIN1" Bin 1 "BIN 1" Bin 1 "01" Bin 1 "Bin01" 👉 電腦比對時是「逐字元完全相等」 只要有一個空白、一個前綴，結果就會不同。 二、問題的真相： Bug 不是資料錯，而是「工程假設錯」 這次案例的核心問題可以用一句話總結： ❌ 系統用「顯示用的字串」來當「資料比對的依據」 這在工程上是 非常危險的設計 。 三、系統中實際發生了什麼事？（白話版） 我們來拆解一個常見的資料流程： 原始資料 ↓ 整理 / 合併 ↓ 分類（Bin） ↓ 轉成報表用格式 ↓ 顯示在畫面 問題發生在這裡 👇 ❌ 錯誤流程（很多系統都這樣做） 使用者選擇「我要看 Bin1、Bin5、Bin19」 系統拿「畫面上看到的字串」去比對資料 發現「怎麼都對不到」 系統很認真地把資料「全部刪掉」 畫面顯示： 沒有 Bin 但其實資料根本沒消失。 四、專業工程師怎麼 Debug 這種問題？ Step 1：先不要猜，直接「印出來看」 第一件事永遠是： 👉 把...

  適合讀者 ： 剛接手 Spotfire 專案的新手 看到一堆表名（RAW_xxx、ASMT_xxx）卻不知道資料從哪來的人 工程師 / 分析師 / BI 使用者 常被問：「這張圖的數字是哪來的？」卻答不出來的人 一句話先講結論（給忙的人） 在 TIBCO Spotfire 裡： 畫面上的結果 ≠ 程式碼直接算出來的 大多數情況是：  SQL 資料庫 → Spotfire Data Table → Data Function 處理 → 圖表顯示 只要你能一路回推這條鏈，就一定能找到「真正的資料來源」。 一、為什麼 Spotfire 會讓人「找不到資料來源」？ 很多人第一次看 Spotfire，會遇到這種情況： 畫面上有一張表，例如： 👉 FT_YIELD_BIN 打開屬性只看到： 👉 Source function: 某個 Python Data Function 再看 Data Function，只看到一個名字： 👉 ft_yield 然後就卡住了 😵 心裡只剩下一句話： 「所以資料到底從哪來？」 二、Spotfire 的資料其實有「三層結構」 用白話說，Spotfire 的資料來源通常分三層： 第 1 層：資料庫（最底層） SQL Server / Oracle / MySQL… 真正存資料的地方 例如某個 Yield、測試、製程資料表 第 2 層：Spotfire Data Table 用 SQL 把資料撈進 Spotfire 表名常長這樣： RAW_xxx ASMT_xxx TMP_xxx 第 3 層：Data Function / Script Python / R 對 Data Table 做「再加工」 例如加總、轉換、比例計算 👉 很多人卡住，是因為只看到第 3 層 三、ft_yield 是什麼？（重點釐清） ft_yield 不是一張表 ，也不是 SQL。 它是： Data Function 的「輸入參數名稱」 白話翻譯就是： 「我這段 Python，需要你給我一批資料欄位來算」 而這批資料，實際上來自 另一張 Spotf...