🐬Spotfire 自動化月報「SQL 明明有資料卻輸出空」？一個欄位名稱大小寫就能讓報表全失敗（附排查步驟）

- 2月 25, 2026

1. 問題情境：為什麼「看起來」像 SQL 回傳空？

在企業環境裡，Spotfire 常會搭配 Automation Services 或排程，在固定時間產出週報/月報（CSV、PDF）。
最常見的抱怨之一就是：

「我在資料庫查得到資料，但 Spotfire 自動化跑完後，輸出的清單是空的、報表沒產生。」

這類問題很容易被誤判成：SQL 寫錯、資料庫掛掉、Spotfire 連線失效……
但實務上，真正的原因有時候非常「小」：欄位名稱不一致（尤其是大小寫或拼字）。

2. 真相通常藏在「兩個步驟之間」

一個典型的 Spotfire 自動化流程會長得像這樣：

產生 SQL（依週/月日期區間）
把 SQL 丟給資料表或資料來源更新
從資料表中抓某個欄位的 distinct 值（用來逐一輸出每個產品/機種/客戶的報表）
套用篩選條件
匯出 CSV / PDF

很多人只檢查第 1 步（SQL），看到資料庫有資料就放心了。
但真正在「輸出空」的案例中，常常是第 3 步出了問題：

✅ SQL 有資料
❌ 但「抓 distinct 的欄位」寫錯了，所以取得的清單是空的
➡️ 清單空 = 不會跑迴圈 = 不會輸出任何檔案
➡️ 最後就被誤會成「SQL 回傳空」

3. 典型錯誤：欄位名一個字不同，清單直接變空

假設你的資料表裡欄位叫做 Device（D 大寫，其它小寫），週報用這個欄位去取 distinct 是正常的：

週報：取 Device ✅

但月報不小心寫成 DEVICE（全大寫）或 device（全小寫），有些環境下就會：

回傳空清單 []
甚至不丟錯（最麻煩，因為你以為成功）

結果就是：
SQL 明明查得到資料，報表卻一張都不出。

4. 如何用「非工程師也懂」的方式理解？

你可以把整個流程想像成：

資料庫＝倉庫（裡面很多貨）
SQL＝你跟倉庫說「幫我把 12 月的貨拿出來」
distinct 清單＝你在貨上貼標籤，想分成「A 品牌、B 品牌、C 品牌」再分別打包
但你貼標籤時，把標籤名稱打錯（例如本來叫「品牌」，你寫成「品牌名稱」）
結果系統找不到標籤，就以為「沒有任何分類可以打包」
最後：貨在倉庫裡，但你一箱都沒寄出去

5. 最快排查法：用「兩個驗證」秒殺問題

當你遇到「Spotfire 自動化輸出空」時，請依序做下面兩件事：

驗證 A：SQL 在資料庫真的有資料嗎？

用最簡單的 count 驗證區間（例如上個月整月）：

只看有沒有資料筆數（不看內容）
確認日期區間沒算錯

如果 count > 0：代表 SQL 區間與資料本身沒問題。

驗證 B：Spotfire 裡那張資料表更新後，RowCount 是多少？

即使 SQL 有資料，也要確認「Spotfire 的資料表」真的有更新到資料。
最穩的做法是印出：

RowCount（筆數）
Columns（欄位清單）

如果 RowCount > 0，但 distinct 清單卻是空：
✅ 99% 是「取 distinct 的欄位名寫錯」

6. 常見延伸問題（也很常踩）

除了欄位名之外，還有幾個「容易讓結果變空」的陷阱：

6.1 日期格式不一致

有些人週報用 YYYY/M/D，月報用 YYYY-MM-DD，在不同語系/設定下可能解析不同。
建議統一用 ISO 格式：YYYY-MM-DD，並搭配「左閉右開」區間：

>= start
< end

這種寫法對「包含整天資料」也更安全。

6.2 同一天同時跑兩段邏輯

例如：同一天既符合「星期三週報」又符合「28 號月報」，就會連跑兩次。
如果沒做互斥（例如用 elif），log 看起來會像「跑完又跑一次」，容易誤判。

7. 最佳實務：讓錯誤變得「立刻看得懂」

在企業環境中，真正能省最多時間的不是「修好一次」，而是讓下次更快定位。

建議你在排程腳本裡固定輸出三類訊息：

這次跑的日期區間（start/end）
Spotfire 資料表 RowCount
distinct 清單筆數（例如 deviceList count）

這樣下次看到「清單 0」就知道是欄位名或取值問題，不會再花一小時懷疑資料庫。

結語：別急著怪 SQL，先檢查「資料取值的那一段」

Spotfire 自動化報表的坑，常常不是在 SQL，而是在：

取 distinct 的欄位名拼錯 / 大小寫不一致
資料表其實沒更新到
日期區間算到你不期待的月份

只要用「SQL count + Spotfire RowCount + distinct 清單」三連驗證，幾乎可以在 5 分鐘內定位問題。

搜尋此網誌

小小大大學