在PHP 7.3使用interbase extension的function ibase_query, 當ibase_query有數值的argument時, 會出現找不到紀錄或出現錯誤訊息: “arithmetic exception, numeric overflow, or string truncation”

分析:
文字argument不會出現問題。在PHP 5運行時也沒有問題。

解法:
將數值變量直接嵌入query裡。

教訓:

1. 版本升級不只是「語法相容」
   同一套程式碼在 PHP 5 正常，在 PHP 7.3 出現 arithmetic exception, numeric overflow, or string truncation，代表底層 extension 或資料庫驅動行為已經改變，而不只是語言本身語法差異。

看到「同一段 SQL、同一筆資料，在不同 PHP 版本結果不同」時，要優先懷疑：extension 的型別轉換、參數處理順序或預設設定是否改變，而不是只從 SQL 邏輯著手。

2. 數值參數與文字參數的行為差異要特別警惕
   問題只在「數值型」 argument 出現，而文字 argument 正常，說明 ibase 擴展在處理 PHP 的 int/float 轉 Firebird/InterBase 的 numeric/decimal 時，可能有額外的轉型或精度問題。

將同一個變量改成字串拼入 SQL 後就正常，基本可判斷是「綁定參數 → 底層型別轉換」這一段出錯，而不是資料本身或 SQL 邏輯錯。

3. 當錯誤訊息與實際問題不對應時，要懷疑型別或編碼
   arithmetic exception, numeric overflow, or string truncation 這類訊息在 Firebird/InterBase 裡相當籠統，可能是：

數值超出欄位可表示範圍

小數精度不符

字串長度／編碼不符

這次實際原因不是運算公式，而是「PHP 傳入的數值參數經 extension 轉換後，與資料庫定義不相容」。遇到類似錯誤時，除了檢查 SQL 邏輯，也要檢查：

參數型別（int / float / string）

資料庫欄位定義（numeric(precision, scale)）

是否有隱性 cast。

4. 工具／函式介面行為改變，要用「最小不意外」原則繞過
   解法是「把數值變量直接嵌入 query 字串」，等於繞過 ibase_query 的數值參數型別轉換路徑，改為由資料庫自行解析字面值。

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