🔎如何在 Oracle PL/SQL 儲存過程中為文字欄位加入換行符號（CHR(10)）——以 Updlcmremark 為例

-

 

前言

在企業級系統開發中，我們常會將複雜的商業邏輯封裝成 Oracle PL/SQL 的儲存過程（Stored Procedure），以便重複使用並確保邏輯一致性。
這次的案例是 修改 Updlcmremark 儲存過程，目的是讓產出的 REMARK 欄位在資料庫中具有「換行」格式，而不只是用逗號分隔，方便報表與前端顯示。



問題背景

原本的 Updlcmremark 過程中，對於某些資料（例如來自 APS_Z_LCM_CHECK 的 process_step 與 eq），是直接用字串拼接的方式： 

v_remark := NVL(v_process_step, '') || '' || NVL(v_eq, '');

這種寫法的缺點是：

  1. 資料之間沒有任何分隔符號，閱讀性差。

  2. 若要在前端或報表中換行，必須額外處理，不方便。

  3. 如果一個 SEQ_NO 有多筆資料，這種寫法只會取到第一筆（FETCH 單筆），其他資料會被忽略。



改進需求

參考同系統的另一支儲存過程 Updmremark，該過程在拼接文字時不僅使用逗號分隔，還加上換行符號： 

|| ' ,' || CHR(10)

這樣在資料庫中儲存的內容，就會自帶換行，即使直接查詢或匯出到 Excel 報表，也能保有可讀性。



解決方案

方案一：簡單版（單筆取值加換行）

如果 unknown 游標一次只需要取一筆資料，可以直接在原本字串後加上逗號與換行符號： 

v_remark := NVL(v_process_step, '') || ' ' || NVL(v_eq, '') || ' ,' || CHR(10);

這樣每筆 remark 都會以「逗號 + 換行」結尾。



方案二：完整版（多筆累加加換行）

如果 unknown 游標可能有多筆資料，則應該使用 FOR rec_unknown IN ... LOOP 迴圈將所有資料串接起來： 

v_remark := '';

FOR rec_unknown IN unknown(rec_data.SEQ_NO, rec_data.APS_VERSION) LOOP
  v_remark := v_remark ||
              NVL(rec_unknown.process_step, '') || ' ' ||
              NVL(rec_unknown.eq, '') || ' ,' || CHR(10);
END LOOP;

-- 去掉最後一筆多餘的逗號
IF SUBSTR(v_remark, -2, 1) = ',' THEN
  v_remark := SUBSTR(v_remark, 1, LENGTH(TRIM(v_remark)) - 2) || ' ';
END IF;

優點：

  1. 不會漏掉多筆資料。

  2. 每筆資料佔一行，報表與查詢結果清楚易讀。

  3. 格式與 Updmremark 一致，維護性高。



CHR(10) 在 Oracle 的作用

CHR(10) 在 Oracle 代表 換行符號（Line Feed, LF），它等同於 ASCII Code 的 10，通常在 Unix/Linux 系統下就是換行的意思。
如果在 Windows 環境中需要 CRLF（\r\n），則可以使用： 

CHR(13) || CHR(10)

其中：

  • CHR(13)：Carriage Return (CR)

  • CHR(10)：Line Feed (LF)



最終效果

假設 process_step 與 eq 分別為： 

"檢測"、"EQ01"
"包裝"、"EQ02"

儲存後的 REMARK 欄位會是： 

檢測 EQ01 ,
包裝 EQ02 ,

每一筆後面都有逗號和換行，查詢與匯出時的格式將非常清晰。



結論

這次的改動雖小，但卻大幅提升了資料的可讀性與維護性，特別是在報表輸出與前端顯示上，可以直接利用資料庫原始內容呈現換行，而不需要額外處理字串格式。

關鍵重點：

  1. 用 CHR(10) 在 Oracle 中加換行。

  2. 如果有多筆資料，記得用 FOR LOOP 累加而不是單筆 FETCH。

  3. 去除最後一筆多餘的分隔符號，避免格式不整齊。

留言

張貼留言

這個網誌中的熱門文章

🔍Vue.js 專案錯誤排查：解決 numericFields is not defined 與合併儲存格邏輯最佳化

-
  前言 在前端開發專案中，處理表格數據與 Excel 匯出是常見的需求。 最近在專案中，遇到一個常見但讓人頭痛的錯誤訊息： Uncaught ReferenceError: numericFields is not defined 本文將用簡單的方式，帶你了解這個錯誤的成因、如何修改程式碼，以及如何最佳化「合併儲存格」與「數值加總」的邏輯。 問題場景：表格合併與數值加總 專案中需要達成以下功能： 同一個 APS_PLAN_NO 下，若 TFT4 相同，則 TFT5 欄位要合併。 數值欄位要加總，並以千分位格式輸出。 匯出到 Excel 時，也要套用相同邏輯。 在 Vue 的 rowSpans 計算邏輯中，初始版本如下： const rowSpans = computed ( () => { const rows = filteredData. value const spans = rows. map ( () => { const obj = {} tableHeaders. value . forEach ( key => obj[key] = 0 ) return obj }) ... return spans }) 但是，當我們在 exportToExcel() 使用時，出現了以下錯誤： Uncaught ReferenceError: numericFields is not defined 錯誤原因 這個錯誤訊息代表： 👉 numericFields 在程式中根本沒有宣告，所以瀏覽器不知道它是什麼。 舉例來說，假設我們在程式裡寫了這樣的判斷： if (numericFields. includes (key)) { // 處理數值欄位 } 但其實 numericFields 沒有定義，程式就會直接報錯。 解決方案：定義 numericFields ...
閱讀完整內容

🛠【ASP.NET Core + Oracle】解決 ORA-00904 "FALSE": 無效的 ID 錯誤與資料欄位動態插入顯示問題

-
  🔍 問題描述 在開發群創光電內部的 APS 排程系統（使用 ASP.NET Core + Vue 3 + Oracle），前端發生多筆錯誤訊息： Request failed with status code 500 Oracle.ManagedDataAccess.Client.OracleException: ORA-00904: "FALSE": 無效的 ID 這是 Oracle 資料庫對布林值處理不一致造成的錯誤，我們後端嘗試將某個欄位 .Where(x => x.FLAG == false) 寫法，經由 EF Core 轉成 SQL： SELECT * FROM TABLE WHERE FLAG = FALSE 而 Oracle 並不支援 FALSE 關鍵字作為布林值 → 導致查詢失敗。 🔧 解決方案 1：避免布林值直接進入 LINQ to SQL EF Core + Oracle 不支援下列語法： .Where(x => x.IsActive == false) // ❌ Oracle 無法解析 FALSE ✅ 解法 ：將布林判斷移至 .ToList() 之後，變成記憶體篩選： var list = await db.Table.Where(x => x.Version == ver).ToListAsync(); var filtered = list.Where(x => !x.IsActive).ToList(); // ✅ 在記憶體中比對布林 🔧 解決方案 2：安全轉換 SEQ_NO 為 Decimal 後端為了將前段表 APSZFRONT 的 SEQ_NO 與 APSZLCM 的 APS_PLAN_SEQ 對應，用到了這段程式碼： Convert.ToDecimal(front.SEQ_NO) 但一旦 SEQ_NO 含有英文字母（例如 GN140CHCAAE90S_20250811_1_531 ），就會丟出 FormatException → 造成 HTTP 500。 ✅ 正確寫法（TryParse 避免失敗） ： de...
閱讀完整內容

🔎EF Core 連 Oracle 出現 ORA-00600 [kpp_concatq:2] 的完整排錯指南（含 EF Core ToString/CultureInfo 錯誤）

-
  摘要（Meta Description） 在 .NET EF Core 對 Oracle 查詢時，若遭遇 ORA-00600 [kpp_concatq:2] ，多半是查詢優化器在字串型別轉換或重寫（Query Transformation）時踩到版本 Bug。本文以實戰日誌形式，示範如何用 FromSqlRaw + 參數型別/長度對齊 + CAST + Hint 立即止血，並處理 EF Core 另一個常見錯誤：「 CultureInfo 常值被傳進 ToString 造成可能記憶體外洩 」。附可直接套用的程式碼。 目錄 錯誤現象 根因分析 三步驟「立即止血」 安全重構：可直接貼用的程式碼 進階避雷：CTE/MATERIALIZE 與 View 包裝 EF Core ToString / CultureInfo 錯誤的正確處理 版本與長期解法（根治） 效能與穩定性小技巧 檢查清單（Checklist） FAQ 結語 錯誤現象 常見堆疊片段如下（節錄）： Oracle .ManagedDataAccess .Client .OracleException ( 0 x80004005): ORA-00600 : 內部錯誤代碼, 引數: [kpp_concatq:2] , [4] , [3] ...
閱讀完整內容