小小大大學

📘 內容（完整教學） 🚨 一、常見錯誤現象（你可能遇到這些） 如果你在 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...

🌟 前言：工程師最常遇到的資料庫問題 在企業系統與後端開發中， Stored Procedure（儲存過程） 是資料處理的重要工具。 然而許多開發者或使用者常遇到以下問題： 明明改了程式碼，執行結果卻還是舊的？ Stored Procedure 執行顯示成功，資料表卻完全沒有更新？ 使用 execute 指令，卻什麼都沒有發生？ 如果你也遇過這些情況，恭喜你！ 這篇文章將用 完全不需要工程背景也能理解的方式 ，帶你找出真正原因。 🧩 Stored Procedure 是什麼？用生活例子說給你聽 想像你有一台自動咖啡機。 你按下「拿鐵」按鈕 咖啡機照著內部設定好的步驟做出拿鐵 每次按下按鈕它就重複執行相同流程 Stored Procedure 就像資料庫的「拿鐵按鈕」： 系統呼叫它 它會依照程式碼的流程讀資料、計算、回寫資料 結果會影響資料表 但有一個很重要的重點： ❗ 如果你更新了咖啡機內部程式，但沒有按「儲存」，它仍會用舊的流程做咖啡。 資料庫也是一樣。 🚨 常見問題：明明改了程式碼，資料卻沒有更新？ 讓我們看一個簡化後的示例程式碼（已完全改寫，不含任何真實欄位）： PROCEDURE UpdateCustomerStatus(p_id NUMBER) AS BEGIN -- 依據客戶編號更新狀態 UPDATE customer_data SET status = 'ACTIVE' WHERE id = p_id; END ; 你後來把更新邏輯修改成： SET status = 'VERIFIED' 但是你執行後卻發現： 狀態仍然顯示 'ACTIVE' 資料完全沒有變化 但 SQL Developer 顯示 “Procedure completed successfully” 為什麼？ 🔍 原因 1：你沒有真正編譯（Compile）Stored Procedure SQL Developer 中的情況就...

前言：為什麼「排程顯示 Completed」不代表你想要的流程都成功？ 很多人第一次使用 Spotfire Automation Services ，會以為： Scheduled jobs 顯示 COMPLETED 就代表「資料有更新、腳本有跑、PDF 有輸出」✅ 但實務上常遇到的狀況是： 排程顯示 COMPLETED，但匯出的檔案是舊資料 手動跑 OK，自動排程卻失敗 明明設定了 Script，卻不知道它到底有沒有被執行 看得到 Job name，但找不到「到底跑了哪些步驟」 這篇文章會用「完全沒接觸過的人也能懂」的方式，帶你把整個執行流程拆開來看。 一句話先懂：Scheduled Jobs 只是「外殼」，真正流程在 Library Spotfire Automation Services 的概念可以用一句話理解： Scheduled Jobs ：排程表（像 Windows 工作排程器的清單） Library 裡的 Job 定義 ：真正的流程腳本（像 .bat / pipeline / workflow） 所以你在 Scheduled Jobs 看到的資訊，通常只有： Job 名稱 Job path（例如 /DEV/FT Auto ） 最後狀態（Completed / Failed） 下次執行時間 但你想看的這些， 不會出現在 Scheduled Jobs： 用哪個 .dxp 跑了哪些 Script Script 做了哪些事（刷新資料、換頁、匯出、存檔） 匯出 PDF / Excel 到哪裡 1）如何找到「真正的執行流程」：跟著 Job path 走 你會在 Scheduled Jobs 看到一個 Job path ，例如： /DEV/CP Auto /DEV/FT Auto 這個 path 就像「資料夾路徑」，代表真正的 Job 定義放在哪。 正確操作 ...

🧩 前言：為什麼「排程成功」卻什麼都沒有？ 在企業系統中，我們常會用 Windows 工作排程器（Task Scheduler） 來自動執行報表、資料匯出或後端程式。 但你是否遇過這種情況： 排程顯示「執行成功」 紀錄也顯示「工作完成」 使用者也確實按了「執行」 結果：沒有任何檔案產生 對非工程背景的人來說，這非常困惑： 「不是顯示成功了嗎？那檔案去哪了？」 事實上，這類問題 往往不是排程問題，也不是資料夾路徑錯誤 ，而是 系統層級的程式崩潰 。 🧠 一個關鍵觀念：排程「成功」≠ 程式「正常完成」 Windows 工作排程器只負責一件事： 👉 是否成功「啟動」某個程式 它 不會知道 ： 程式內部是否出錯 程式是否被系統強制中止 程式是否真的跑完商業流程 因此，只要程式「有被叫起來」，排程就可能顯示成功。 🚨 關鍵錯誤碼：RC = -1073741819 是什麼？ 在實務除錯中，工程師最終發現排程回傳了這個值： RC = -1073741819 這不是一般的應用程式錯誤碼。 🔍 換算後的真正意義 -1073741819（十進位） = 0xC0000005（十六進位） 在 Windows 系統中， 0xC0000005 代表： Access Violation（存取違規） 白話翻譯是： 程式在執行時，嘗試存取「不被允許的系統記憶體或資源」， Windows 判定風險過高，直接強制終止程式。 ⚠️ 這是作業系統層級的「殺程序」行為 ❌ 為什麼這不是一般的程式錯誤？ 一般程式錯誤 系統層級錯誤（本案例） 有錯誤訊息 沒有錯誤訊息 ...