部落格

分析:
收不到EDI文件的可能原因:

1. EDI文件沒有被生成。
2. EDI文件沒有被傳送出去。
3. EDI文件內容有錯誤, 導致接收方的系統不保存。

解法:

1. 保存一份已發送的EDI文件的副本, 有需要時可翻查。
2. 重新傳送同一個EDI文件, 登入接收方的SFTP主機確認文件已順利傳送到達。

教訓:
在建立自動化的 SFTP 傳送流程時，必須確保每一個傳送步驟都有可追蹤與可驗證的紀錄。缺乏完善的日誌或檔案副本機制，容易導致問題難以追蹤，特別是當接收方聲稱「未收到」文件時，難以判斷問題發生在哪個環節。

未來在設計類似系統時，應：

為每次文件生成與傳送建立明確的記錄（包括文件名、時間戳記、傳送結果回報）。

保存已傳送文件的副本，以便必要時進行比對與調查。

在可能的情況下，實作接收確認機制（如回覆檔案或狀態回報），確保完整傳輸閉環。

這樣不僅能提升問題排查的效率，也能強化系統間的信任與穩定性。

本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。

分析:
發送方不同數據庫是自行管理公司代碼, 所以代碼在同一數據庫內是唯一, 但在全部數據庫裡未必是唯一。更大的問題是同一個客戶在不同的數據庫可能有不同公司代碼。

解法:

1. 在公司代碼前面加上數據庫代號。
   好處: 簡單
   壞處: 如果同一個客戶出現在多個數據庫, 這個客戶會有多個不同的代碼, 所以代碼並不是唯一。
2. 為每一個客戶編定唯一識別碼。
   好處: 可確定識別碼是唯一的。
   壞處: 可能會花很多時間去確保識別碼是唯一的。

教訓:
提早定義全域唯一識別規範
在多資料來源系統對接前，應先決定唯一識別碼的生成與維護策略。若一開始依賴本地（資料庫內部）代碼作為主鍵，後續整合時幾乎必然出現衝突與對應問題。

避免將內部業務代碼當作跨系統識別碼
公司代碼、客戶代碼等通常是業務邏輯層概念，而非技術上保證唯一的 ID。它們可以保留作輔助欄位，但不應作為整合集成的關鍵識別依據。

建立唯一識別碼需要統一管理機制
若選擇集中式唯一 ID（例如 UUID、全域客戶 ID），需設立負責生成與維護唯一性的權威系統，避免人工重複核對的高成本。

在整合設計中考慮真實業務意義對應
即使技術上有唯一 ID，也要確認能正確反映「同一客戶」的業務實體。必要時應建立「客戶主檔」（Master Data Management, MDM）來處理跨系統實體的關聯與比對。

短期方案應可平滑遷移至長期方案
若初期時間有限，可採用臨時方案（如加資料庫代號前綴），但需為未來導入統一 ID 預留遷移機制，避免資料重構困難。

聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。

分析:
嘗試過用combatibility mode運行, 還是出現相同的錯誤訊息。

解法:

1. 在較舊的Windows版本(如 Windows 10, 7)運行 (不建議, 因舊的Windows版本已沒有支援)
2. 使用其他version control software, 如 Git, Subversion

教訓:
在使用舊版軟體（例如 Team Coherence）於新作業系統（如 Windows 11）時，可能會因系統相容性及舊程式庫依賴（例如 Kernelbase.dll）而導致錯誤。這提醒我們：
要定期評估並更新開發工具，以避免因不再維護的軟體造成相容性問題。
應盡早規劃遷移至現代化版本控制系統（如 Git 或 Subversion），確保工作流程穩定且能獲得持續支援。
在導入或升級作業系統前，宜先驗證關鍵工具的相容性，預防影響開發效率。

聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。

分析:

1. Arithmetic Exception的最常見原因是算式出現除以0。
2. Numeric overflow的原因是數值超出欄位的最大值。
3. 字串過長。

解法:

1. 尋找除數算式, 可嘗試加入Check確保不會除以0。
2. 確保數值不超過欄位的最大值。考慮使用最大值更大的data type。
3. 擴大欄位的字串長度, 或者保存字串到欄位前先trunc到合適長度。
4. Cast NULL to a Non-Nullable domain/type

教訓:
在 Firebird SQL 的 View 中，遇到「算術異常、數值溢出或字串截斷」錯誤時，通常源於資料計算或轉換過程中的邊界條件未妥善處理。

聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。

分析:
某些Object, Array或Pointer指著的位址超出容許的範圍, 常見的是nil object或null pointer下存取屬性, 或者存取未initialize的Array的Item。

解法:

1. 存取object或pointer下的屬性前, 先確保object不是nil或Pointer不是null。
2. 存取Array的item前, 必須先initialize array (e.g. SetLength to 0)

教訓:
在Delphi開發中，”Access violation” 通常代表嘗試存取一個無效的記憶體位址。這往往是因為程式在使用 nil object、null pointer 或尚未初始化的陣列。開發人員必須在操作物件或指標前確認其有效性，並在使用陣列前適當初始化。

聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。

問題: 從網站讀取本地服務器的相片可能受本地服務器的網速限制而變慢。
分析: 上傳相片到本地服務器的速度可以很高，但每次經網絡存取本地服務器的相片可能會慢。客戶的體驗應優先於員工的體驗。
解法: 將相片先上傳至雲端，再將連結存放在本地服務器。在網站顯示雲端的連結供客戶自行檢視。
教訓:
以使用者體驗為導向設計系統架構
在系統設計中，資料的儲存與存取方式不只是技術選擇，更直接影響客戶的使用體驗。雖然將相片儲存在本地服務器能在上傳階段提升效率，但若訪問速度受限於內部網絡頻寬，就會造成客戶端顯示緩慢，影響整體滿意度。
因此，設計時應優先考慮外部使用者的訪問效率與穩定性，將靜態資源（例如相片）上傳至雲端儲存平台，並透過公開或授權的雲端連結提供存取。此舉可同時兼顧內部操作效率與客戶端體驗，減少本地網絡瓶頸帶來的性能問題。

聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。

分析: 跟Pointer有關的代碼出問題
解法: 對照代碼修改了的部份, 發現某些Object Free了兩次。
教訓: Object Free了後應assign為nil, 即使錯誤地再Free亦不會出錯誤訊息。

背景:
使用WinSCP作為SFTP client, 上傳文件時, 會生成 xxx.filepart檔。成功上傳後變回原檔名 (xxx)。

問題:
上傳中途斷線, 殘留了 xxx.filepart檔。重新上傳同一檔案會出錯誤。

分析:
重新上傳同一檔案時會生成xxx.filepart檔, 因xxx.filepart檔已存在, 估計是因為連接仍然存在, 不能覆蓋, 所以出錯誤。

解法:
方案1: 手動刪除xxx.filepart檔: 要先關掉SFTP Server軟件或重啟SFTP Server主機才可以成功刪除。
方案2: 在SFTP Server軟件設定合理的Idle timeout, 讓xxx.filepart檔適時解鎖。

教訓:
使用 SFTP 工具（如 WinSCP）進行檔案上傳時，必須考慮中斷傳輸後的檔案鎖定與清理機制。若未妥善處理，殘留的 .filepart 檔案可能導致後續上傳失敗，影響部署或資料更新流程。

聲明：本作品包含在人工智慧協助下產生的內容。作者已對所有材料進行驗證與編輯，以確保其準確性與完整性。