🐬Spotfire 自動報表 SQL 日期格式差異：為什麼同一段查詢在 Run Rpt 有資料、AutoReport 卻沒資料？

前言：同一個報表，為什麼「手動跑」有資料，「自動跑」卻變成空？

很多做報表自動化的人都遇過這種情境：

• 在工具的「Run Report / Run Rpt」手動執行 SQL，資料正常、圖表正常。

• 但換成 Spotfire 的 IronPython 腳本自動跑，同一份 SQL 生成的資料表卻是空的，甚至抓不到任何 Device 清單可輸出。

這篇文章會用「軟體工程師對完全不懂的人」的方式，帶你理解：

1. SQL 日期格式差異 到底會造成什麼結果

2. Spotfire 看到 Replace 成功，不代表真的有資料

3. 為什麼 device 和 DEVICE 這種大小寫差異會害你拿不到清單

4. 想改用 replaceDBDS 卻出現 name is not defined，該怎麼處理

5. 最後給你一套穩定、可維護的排查流程

---

1) 先釐清：你其實在做兩件事

你的自動報表腳本大概會做這類事情：

1. 用 SQL 從資料庫撈資料（含 Pivot，把 wafer 1～25 轉成欄位）

2. 把資料塞進 Spotfire 的 Data Table

3. 從 Data Table 取得 distinct Device 清單

4. 逐一套用篩選、輸出 CSV / PDF

所以如果你後面拿到 Device 清單是空，不一定是篩選或輸出錯，而可能是「前面資料根本沒進來」。

---

2) 日期格式差異：為什麼看起來一樣，其實可能不一樣？

你可能看過這兩種寫法：

• StopTime > '2026/1/19' and StopTime < '2026/1/26'

• StopTime > '2026-01-19' and StopTime < '2026-01-26'

對人類來說都看得懂，但對 SQL Server 來說，它需要把字串轉成日期時間。這個轉換如果碰到「系統語系、日期設定」不同，就可能出現：

• 日期被解析成不同值

• 或解析失敗

• 或條件範圍不如你想像（例如少抓一天、或完全抓不到資料）

工程師常用的建議：

• 最穩 的日期寫法是 ISO 格式（YYYY-MM-DD 或 YYYY-MM-DDTHH:MM:SS）

• 如果你硬要寫成 YYYY/M/D（像 Run Rpt），也要確保資料庫能正確解析

---

3) 「Replace 成功」≠「有資料」

你可能在 Console 看到類似輸出：

• True（看起來替換成功）

• 但 Device 清單是 []

這代表什麼？

最常見的兩種可能：

可能 A：SQL 查回來就是 0 rows

也就是時間區間、條件、或資料真的沒有落在這段範圍。

可能 B：欄位名稱不一致（尤其是大小寫）

你的 SQL 可能寫：

• select device, lotno, ...

但你程式抓的是：

• GetColumnDistinctValues(tableName, "DEVICE")

結果 Spotfire Data Table 欄位叫 device（小寫），你去抓 DEVICE（大寫）就會抓不到，直接空清單。

✅ 所以工程師排查時一定先做兩件事：

1. 看 Data Table 的 RowCount（有沒有資料列）

2. 把欄位名稱全部印出來（確認到底叫什麼）

---

4) 讓欄位永遠一致：用 SQL Alias 解決大小寫地雷

最簡單、最可維護的作法是：在 SQL 直接把欄位 alias 成你程式要的名字。

例如你程式要用 DEVICE，那 SQL 就固定輸出 DEVICE：

• device as DEVICE

• lotno as LOTNO

• grossdie as GROSSDIE

這樣你後面：

• 取 distinct values

• 寫篩選條件（[DEVICE]='xxx'）
  都不會被大小寫或欄位名改動影響。

---

5) 為什麼你想用 replaceDBDS 卻一直報錯？

你遇到的錯誤長這樣：

name 'replaceDBDS' is not defined

這句話翻成白話就是：

「我在你的腳本裡找不到 replaceDBDS 這個東西。」

原因通常是：

• replaceDBDS 不是全域函式

• 它可能是某個物件的方法（例如某個 API 類別底下）

• 或是你們環境根本沒有提供這個函式

✅ 工程師做法：不要猜，直接列出可用的方法清單
最常見的作法是：把 API 物件有哪些方法列出來，找包含 replace 的名字。
（注意：實務上方法名稱大小寫可能不同）

找到了正確名稱後，再用「物件.方法(...)」的方式呼叫，而不是直接寫 replaceDBDS(...)。

---

6) 一套實戰排查流程（照做就能快速定位）

當你遇到「自動報表沒資料」或「清單是空」時，建議按這個順序排查：

1. 先輸出 SQL 字串（確認 where 條件真的長你想要的樣子）

2. 先跑最簡單的 SQL（例如 count）確認範圍內到底有沒有資料

3. 替換 Data Table 後印 RowCount

4. 印 Data Table 欄位名稱清單（確認 DEVICE 是否真的存在）

5. 再去跑 distinct values / 篩選 / 匯出

6. 若要換成新的替換方法（例如 replaceDBDS），先確認該方法在環境中是否存在

---

結語：穩定的自動報表，靠的是「可預期」而不是「剛好能跑」

在報表自動化裡，最可怕的不是語法錯，而是：

• 看起來成功（True）

• 但其實沒有資料

• 或欄位名不一致導致後面全部流程失效

你只要掌握三個關鍵，就能把自動報表穩定度拉起來：

✅ 日期格式用穩定可解析的格式
✅ 欄位用 SQL alias 固定命名
✅ Replace 後先驗 RowCount + 欄位清單，再做後續輸出