小小大大學

🌟 前言：為什麼 Stored Procedure 執行了卻沒效果？ 在企業系統開發中，你一定遇過這種情況： ✔ 程式碼已修改 ✔ 按了執行 ❌ 資料完全沒變 ❌ 還是舊邏輯 很多人會懷疑： 👉「是不是資料庫壞掉了？」 其實 90% 的原因都是： 👉 執行方式錯誤 + 沒有 Compile 這篇會用「圖文＋一步一步」帶你搞懂。 🧩 Stored Procedure 是什麼？（新手版） 你可以把它想成： 👉「資料庫裡的一個自動化腳本」 就像： Excel 巨集 自動咖啡機按鈕 一鍵報表生成 你呼叫它，它就會： 抓資料 做邏輯判斷 寫回資料庫 🖥 步驟一：修改 Stored Procedure 後一定要 Compile 當你修改程式碼後： 👉 一定要按 Compile（編譯） ✔ 成功訊息應該是： Procedure compiled ❗ 如果沒 Compile 會發生什麼？ 👉 資料庫仍然使用「舊版本」 這就是你看到： 改了欄位但沒變 改了邏輯但沒生效 的真正原因。 🖥 步驟二：正確執行 Stored Procedure 很多人會寫： execute run_job( 'TEST_001' ); ❌ 這在 Oracle 很常「看起來成功但實際沒跑」 ✅ 正確寫法（一定要用這個） BEGIN run_job( 'TEST_001' ); END ; / ❗ 為什麼最後要加 / ？ 👉 這是在告訴 Oracle： 「現在這整段 PL/SQL 可以執行了」 沒有 / → 不會真的執行 🖥 步驟三：確認資料是否真的更新 執行後，請一定要查資料： SELECT * FROM result_table WHERE batch_id = 'TEST_001' ; 👉 不要只看「執行成功」 🧪 進階：開啟 D...

  🧠 前言： 「我明明設定 BIN 加起來要超過 0.1% 才顯示， 為什麼畫面上還是看到一堆 0.00% 或空白的 BIN？」 如果你有做過 BI 報表、資料視覺化或製造數據分析 ，一定遇過這種情況： SQL 裡已經寫了門檻條件 查出來的資料「理論上」應該被過濾掉 但報表畫面上 BIN 欄位還是全部出現，甚至看起來像沒資料 這不是你眼花，也不是系統壞掉， 而是 「資料過濾」與「畫面顯示」是兩件完全不同層級的事情 。 🧩 先用白話講整個資料流程（給完全沒寫過程式的人） 我們把整個系統想成三個步驟： ① 資料庫查資料（SQL） 👉 決定「哪些資料列要留下來」 ② 系統加工資料（資料轉換 / 彙總） 👉 把資料整理成「適合報表顯示的形狀」 ③ 報表畫面顯示（表格 / 圖表） 👉 決定「哪些欄位要顯示在畫面上」 💡 關鍵重點： 就算你在第 ① 步過濾掉資料 第 ③ 步如果「硬把欄位加進畫面」， 那些欄位一樣會出現（只是值是空或 0） ❌ 常見誤解： ###「我在 SQL 裡設定門檻，欄位就不會顯示了」 這是 90% 工程師一開始都會犯的錯誤 。 實際上： SQL 只能控制「資料列」 報表系統（例如 BI 工具） 不會自動幫你隱藏「全空的欄位」 🔍 真正的三大問題根源（工程師角度） ❗ 問題一：你只過濾「資料」，但沒有過濾「欄位」 很多系統會這樣做（示意）： 「把所有 BIN 欄位都加到畫面上」 即使某個 BIN： 沒有任何資料 全部是 0 顯示成 0.00% 👉 它還是會被顯示出來 📌 解法思維（概念）： 在顯示前，先計算「整個欄位的總和」， 小於門檻的欄位，直接不要顯示。 ❗ 問題二：資料 Join（合併）時，用錯層級的 ...

🧠 前言：為什麼「Excel 匯出」其實一點都不簡單？ 很多人以為： 「不就是按一個『匯出 Excel』的按鈕嗎？」 但實際上，在系統背後，這個按鈕通常做了 十幾個以上的步驟 。 如果處理不好，就會出現這些你一定看過的狀況： 數字在 Excel 裡 不能加總 1,234 變成文字，不是數字 欄位順序亂掉 匯出後格式全壞，要手動重調 這篇文章，我會 不用專業術語 ，用「生活化比喻」帶你理解： 👉 一個系統是怎麼「把畫面上的資料，變成一份正常可用的 Excel 檔案」 🧩 一、先搞懂一件事：系統裡的資料 ≠ Excel 的資料 在系統畫面上看到的資料，通常是： 從資料庫來 經過程式加工 顯示成「看起來像數字的文字」 📌 重點來了 在電腦世界裡： 「看起來像數字」跟「真的能算的數字」是兩回事 舉個完全不寫程式的例子 畫面看到 Excel 認為 1,200 一段文字 1200 真正的數字 如果系統沒有特別處理，Excel 只會說： 「我不知道你要算什麼，我只看到一串字」 🔄 二、匯出 Excel 的真正流程（白話版） 你可以把「匯出 Excel」想成 包裹寄送流程 ： 📦 Step 1：先確認「包裹裡有沒有東西」 系統第一件事不是匯出，而是先問： 「目前畫面上真的有資料嗎？」 如果沒有資料，與其產生一個空白 Excel，不如直接告訴使用者： 「目前沒有可匯出的內容」 🗂️ Step 2...

內容 你在 Spotfire 報表上看到一個欄位，例如「Job No.」，常常會遇到這幾個問題： 這個欄位 到底是從哪張資料表來的 ？ 它是從資料庫查出來的？還是 Spotfire 自己算出來的？ 我想修改欄位來源或顯示內容， 要改 Spotfire？還是要改 SQL？ 我知道資料庫叫 xsemi_dev ，但不知道 CUST_PO_NO 這個欄位在哪張表， 怎麼快速找？ 這篇文章用「軟體工程師講給完全不懂的人」的方式，帶你一次搞懂 Spotfire 欄位來源與資料庫欄位搜尋。 一、先搞懂兩件事：Spotfire 的「表格」不等於資料庫的「資料表」 很多新手會混淆： 資料庫資料表（Database Table） ：真正存資料的地方，例如 SQL Server 的某張 dbo.xxx 。 Spotfire Data Table ：Spotfire 內部的資料集（像一個載入後的資料快照），可能來自： 資料庫查詢（SQL） CSV/Excel 檔案 Information Link Spotfire 自己產生或計算欄位 Spotfire Visual（視覺化） ：畫面上的表格、圖表。它只是「把某個 Data Table 的欄位拿出來顯示」。 簡單比喻： 資料庫 = 廚房食材倉庫 Spotfire Data Table = 把食材拿出來放在料理台上  Spotfire 表格視覺化 = 把料理擺盤給你看 所以你看到的「Job No.」，要追來源時，順序一定是： 視覺化（Visual） → 綁定的 Spotfire Data Table → SQL/資料來源 → 資料庫資料表 二、Spotfire 看到「Job No.」：先查它綁的是哪個 Data Table 你在 Spotfire 表格上右鍵： 右鍵表格 → Properties（屬性） 點 Data（資料） 分頁 你...

📘 內容（完整教學） 🚨 一、常見錯誤現象（你可能遇到這些） 如果你在 Windows 使用 Docker Desktop，可能會看到以下問題： Docker Desktop 打不開 顯示 Engine 啟動失敗 CLI 出現「找不到連線管道」或「存取被拒」 docker version 只有 Client，沒有 Server 👉 這些其實都指向同一個核心問題： 🔥 Docker 的 backend（WSL 環境）沒有成功啟動 🧩 二、Docker 在 Windows 的運作原理（白話版） 很多人不知道，其實 Docker Desktop 在 Windows 是這樣運作的： 👉 Docker 並不是直接跑在 Windows 👉 而是跑在「WSL（Windows Subsystem for Linux）」裡面 可以想像成： Windows → WSL → Docker Engine 如果 WSL 有問題，Docker 一定壞。 ⚠️ 三、真正的問題來源（最關鍵） 在實務上，這類錯誤 90% 是這三種原因： ❶ Docker 專用的 WSL 沒建立成功 正常應該會看到： docker-desktop docker-desktop-data 但如果沒有 → Docker 無法運作 ❷ Podman 搶走 WSL（超常見） 如果你看到： podman-machine-default 而且還是 Running 👉 代表： Podman 正在使用 WSL Docker 無法建立自己的環境 ❸ 系統沒有開啟虛擬化 / WSL 功能 例如： WSL 功能沒開 Virtual Machine Platform 沒啟用 BIOS 沒開虛擬化 🔍 四、如何確認問題（新手也能看懂） ✅ 檢查 WSL 環境 打開 PowerShell，輸入（這裡用另一組安全寫法）： wsl --list --verbose 👉 你要看的是： 有沒有 docker-desktop 有沒有 docker-desktop-dat...

前言：為什麼「欄位改了」會讓系統出問題？ 在企業系統中，常常會遇到這樣的情況： 原本每天正常匯入資料 某一天因為需求變更， 輸入檔案的欄位或規則被調整 新進資料看起來正常 但舊資料卻顯示錯誤或空白 報表、BI、分析結果開始不一致 這時候很多人會直覺認為： 「我已經把程式改好了，為什麼舊資料沒變？」 這篇文章會用 不需要工程背景 的方式，完整解釋原因與正確做法。 一、什麼是 Loader？用白話講就是「資料搬運工」 你可以把 Loader 想像成一個自動化工人： 從資料夾讀取檔案（例如 CSV、彙總檔） 把檔案內容轉成資料庫可以存的格式 寫入多張資料表 成功就把檔案移到「成功資料夾」 失敗就移到「失敗資料夾」 同時留下「處理紀錄」，方便之後追蹤 重點是： Loader 的主要任務是「處理新資料」，不是「修改舊資料」。 二、Loader 是怎麼分辨 FT1Y 與其他站點的？ 很多人會以為程式裡有這種判斷： 「如果是 FT1Y，就做不一樣的事」 實務上其實不是。 真正的做法是： Loader 會從 檔名或檔案內容 中解析出一個「站點代碼」 例如：FT1、FT1Y、RT1、FT2 這個站點代碼會被存成一個欄位（例如：OP_NAME） 之後所有判斷、查詢、報表，都是靠這個欄位來區分 換句話說： 對 Loader 而言，FT1Y 只是「一個值」，不是「一段特殊程式」 三、為什麼「改了程式」卻修不好舊資料？ 這是整個問題的核心。 Loader 的基本設計邏輯是： 第一次看到的資料 → 建立新紀錄 已存在的資料 → 只更新統計結果，不重寫欄位 也就是說： 程式邏輯改動後 只會影響未來新進的資料 歷史資料會維持「當初寫進去時的樣子」 所以就會出現： 資料時間 ...

前言：為什麼 Spotfire 會跳出 Linked Data report？ 你可能在 Spotfire 看到這種訊息： Linked data report There are some inconsistencies and some data might not be shown accurately.  The matched column … is missing or it has been renamed in the source. 白話翻譯就是： ✅ Spotfire 原本「記得」要拿某些欄位做資料連結（Linked Data） ❌ 但你現在更新/新增的資料來源裡，那些欄位不見了或改名了 ⚠️ 所以 Spotfire 提醒你：某些資料可能會顯示不準確 一句話讓完全新手懂：Linked Data 是什麼？ 把 Spotfire 想像成「兩張表要用同一個欄位對上」。 例如： 表 A：有欄位「員工編號」 表 B：也有欄位「員工編號」 Spotfire 就能用「員工編號」把兩張表連起來，讓你在圖表點一下，另一張表也跟著篩選。 但如果你把「員工編號」改名成「員工ID」或直接刪掉，Spotfire 就會說： 我找不到原本要對應的欄位了！ 這就是本篇的錯誤核心。 這個錯誤會造成什麼影響？ 不一定會讓 Spotfire 整個壞掉，但常見影響有： 某些圖表突然空白 點選某個圖表，另一個圖表不跟著動 篩選器看起來有資料，但視覺化沒反應 報表結果和你預期的不一樣（最危險） 所以看到這個訊息，通常建議要處理，而不是忽略。 Spotfire 欄位缺失的 5 大常見原因（最重要） 1）來源資料「欄位被改名」 最常見：資料提供方改欄位名稱、或你自己在 ETL / SQL 改欄位別名。 ✅ 原來： Status_Flag ❌ 改成： STATUS_FLAG 或 StatusFlag Spotfire 是「逐字比對」，差一個字元都算不一樣。 2）資料轉換後「欄位被吃掉」 很多人不知道：你做了 Pi...