小小大大學

前言：明明今天資料庫沒資料，為什麼匯出還是 2022？ 你可能遇過這種情境： 今天日期是 2026/01/15 你用排程（Automation Services）跑 Spotfire Script 匯出 CSV / PDF 你確定資料庫在這段期間 沒有任何資料 但匯出的檔案打開一看，竟然還有 2022 年 的內容 第一直覺通常會想：「是不是 SQL 日期條件寫錯？」 但實務上更常見的真相其實是： Spotfire 沒有真的重新查資料庫，而是沿用資料表（Data Table）裡的舊資料（快取/Stored Data）。 本文會用「完全不懂 Spotfire / SQL 的人也聽得懂」的方式，帶你一步一步定位原因，並提供可直接套用的修法。 一、先建立正確觀念：Spotfire 匯出時匯的是「畫面上的資料」 很多人以為「匯出 CSV」等於「直接把 SQL 撈出來寫成檔案」，但 Spotfire 常見流程是： Script 先嘗試把某個資料表（Data Table）改成新的 SQL Spotfire 可能 不會立刻重查資料庫 （尤其是 Stored Data、Cache、排程環境） 你的視覺化（TablePlot）仍顯示舊資料 Export 指令把「視覺化目前呈現的資料」輸出成 CSV 所以： ✅ 只要資料表沒刷新，匯出就會是舊資料 即使資料庫早就空了也一樣。 二、怎麼判斷是不是「沒刷新」而不是「SQL 撈錯」？ 最有效的方法是做三個檢查，全部都可以放在腳本裡印 log。 檢查 1：把日期區間印出來（避免日期格式錯誤） 很多腳本會手動拼字串日期，最常犯的錯是少了 - 或沒補零，導致日期變成像 2026-115 這種「看起來像日期但其實不標準」的格式。 ✅ 建議做法：一定印出 start/end，並用固定格式 YYYY-MM-DD 。 # 假設你要抓近 7 天（含今天） from datetime import datetime, timedelta today = datetime.today() start_dt = today - timedelta(days...

📌 前言：為什麼你會需要搬 Spotfire 資料庫？ 在實務上，你很常會遇到這種情境： 想在本機測試 Spotfire Automation 客戶環境不能亂動 → 要複製一份到自己電腦 Server 壞掉 → 要快速復原 想分析 Job / 排程 / Routing 設定 👉 這時候你要做的其實只有一件事： 把 Spotfire 的資料庫從遠端搬到本機 但問題是… ❌ 很多人不知道該備哪個 DB ❌ 還原後連不起來 ❌ Job 查不到資料 這篇會帶你「一步一步」搞懂 👇 🧩 一、Spotfire 架構（新手一定要懂） Spotfire Server 的「核心其實是資料庫」 通常會有兩個關鍵 DB： 資料庫名稱 功能 Spotfire_DB 存設定、Automation Job、排程 Spotfire_Config 存 Server 設定、帳號、節點 👉 這兩個缺一不可！ 🧠 二、你現在在做的事情（白話版） 你可以想成： 把「公司電腦的設定」複製到「你自己的電腦」 流程其實只有 3 步： 遠端 Server → 備份 → 搬檔案 → 本機還原 🛠️ 三、Step 1：從遠端 Server 做備份 📍 目標：把資料庫變成一個 .bak 檔 你可以在 SQL Server 裡執行類似這種指令（⚠️已改寫）： BACKUP DATABASE Spotfire_DB TO D...

前言：為什麼 Spotfire 自動化，常讓新手卡關？ 很多公司在使用 TIBCO Spotfire 時，最後一定會遇到一個需求： 「這份分析報表，可以每天 / 每週 / 每月自動產出嗎？」 於是大家會開始研究 Automation Services ，結果常常卡在這些問題： Script 已經寫好了，為什麼 Automation 看不到？ DXP 已經存到 Library，為什麼排程頁面是空的？ Web 介面找不到「建立 Job」的地方？ Job Builder 到底在幹嘛？ 本機可以跑，Server 為什麼失敗？ 這篇文章會用 工程師白話 + 實戰流程 ，一步一步帶你從 0 到成功。 一、先建立正確觀念：Spotfire 自動化不是「直接跑程式」 新手最常見的誤解 很多人以為 Automation Services 是這樣運作的： 排程 → 直接執行 Script → 輸出報表 ❌ 這是錯的 正確的系統設計是這樣 Spotfire 的自動化其實是「三層結構」： Automation Job ├─ 開啟分析檔（DXP） ├─ 執行分析內的 Script └─ （必要時）儲存結果 👉 Automation Services 只執行「Job」 👉 不會直接跑 Script，也不會直接跑 DXP 二、為什麼你在 Web Automation Services 看到的是「空的」？ 關鍵原因只有一個 因為你還沒有建立「Automation Job 檔案」 Spotfire Library 裡，其實存在三種完全不同的東西： 類型 用途 Automation 看得到嗎 ...

什麼是 Stored Procedure（預存程序）？用白話解釋 如果你把 SQL 想像成「你跟資料庫說要做什麼的指令」，那 Stored Procedure 就像是： 把一串常用的 SQL 步驟「打包成一個按鈕」，以後只要按一次就會自動完成。 對完全沒寫過的人來說，你可以把它想成： Excel 的巨集（Macro） ：把一堆動作錄起來，以後一鍵執行 咖啡機按鈕 ：你不需要每次研究怎麼磨豆、幾度水溫，你只要按「拿鐵」就會出來 Stored Procedure 的好處 可重複使用 ：同樣的查詢/更新不用每次重寫 較好維護 ：邏輯集中在資料庫端，改一次所有呼叫者都更新 安全性更好 ：可以只授權執行 SP，不必給使用者表格權限 效能常常更好 ：SQL Server 會對 SP 做最佳化（例如執行計畫快取） 在 SSMS 裡 Stored Procedure 通常怎麼寫？ 你在 SSMS 裡新增一個 Stored Procedure，本質上就是寫一段 T-SQL，常見結構是： CREATE PROCEDURE ：建立新的 SP ALTER PROCEDURE ：修改既有 SP EXEC ：執行 SP BEGIN...END ：把多行邏輯包起來 GO ：告訴 SSMS「這段到這裡是一個批次」 範例 1：最簡單的 Stored Procedure（無參數） 假設你常常要查詢最近 50 筆訂單： CREATE PROCEDURE dbo.usp_Order_GetRecent AS BEGIN SELECT TOP ( 50 ) OrderId, CustomerName, OrderDate, TotalAmount FROM dbo.Orders ORDER BY OrderDate DESC ; END ; GO 怎麼執行？ EXEC dbo.usp_Order_GetRecent;...

🧠 前言： 「Excel 明明就有這個欄位，為什麼程式一直說找不到？」 這是 工程師最常被問、也最容易被誤會的問題之一 。 很多人直覺會認為： 👉 「是不是程式壞掉了？」 👉 「是不是我改錯一行？」 但實際上， 問題幾乎從來不在你「改的那一行」 。 🚨 真實情境（簡化說明） 假設你有一個 Excel 檔案，看起來長這樣： LOT_ID PRODUCT QTY A001 IC-123 500 於是你在程式中寫： value = row [ "LOT_ID" ] 結果程式卻跳出錯誤： ❌ KeyError: 'LOT_ID' 你一定會很困惑： 「欄位就在那裡啊？我眼睛沒瞎吧？」 ❗ 關鍵觀念： 👀「你看到的 Excel」≠「程式讀到的 Excel」 這一點非常重要。 🧩 為什麼會發生這種錯誤？（白話版） 原因一： 📄 Excel 的「表頭位置」不是固定的 很多 Excel 檔案其實長這樣： （空白） （說明文字） LOT_ID | PRODUCT | QTY 資料列... 但程式如果 誤把「空白列」或「說明列」當成表頭 ， 那麼真正的欄位名稱就會被當成「資料內容」。 👉 結果就是： 程式以為根本沒有 LOT_ID 這個欄位 原因二： 🧼 欄位名稱有「肉眼看不到的髒東西」 例如： LOT_ID␣ （後面有空白） LOT_ID （不是一般空白，是特殊空白） Lot_ID （前後都有） 人眼看不出來，但程式是 完全不同的字串 。 原因三： 📑 同一家公司，Excel 格式卻不固定 今天的檔案： LOT_ID 在第 1 列 明天的檔案： LOT_ID 在第 3 列 👉 程式如果「假設永遠一樣」，就一定會翻車。 ❌ 常見誤會（一定要澄清） ❗「我只是改了其中一行，為什麼整個程式壞掉？」 因為： 程式在你「真正用到那一行之前」， 就已經先嘗試讀取那個欄位了 所以錯誤並不是你新加的那行造成的， 而是「資料格式不穩定」這件事早就存在。 ✅ 正確的工程師做法（概念版） 工程師不會假設 Excel 是乾淨的 工程師會「先確認表頭，再處理資料」 🛠️ 示意版解法（已全面重寫，非實際程...