首先，虽然你已经排查了常规的算术运算和数值比较，但因为你的表中所有列都是VARCHAR2类型，隐式数据类型转换是最可能触发这个错误的核心原因——Oracle在处理某些比较或函数逻辑时，会自动尝试将字符串转为数字，一旦遇到无法转换的字符就会抛出ORA-01722。

从你的查询语句中，我锁定了几个高风险触发点：

1. 字符串与数字的隐式转换问题 #

你的查询中存在多处对VARCHAR2列进行数值比较的逻辑，比如：

• case when AMOUNT < '1'
• case when ACCRUAL <> '0'
• case when ACCRUAL < '1'

虽然你写的是和字符串'1'、'0'比较，但Oracle的类型转换规则会优先把左侧的字符串列（AMOUNT/ACCRUAL）转换为数字来进行比较。如果这些列中存在任何非数字字符（比如空格、字母、特殊符号，甚至是空字符串），转换就会直接失败，触发ORA-01722。

修复方案： #

不要依赖隐式转换，明确验证字符串有效性后再处理，有两种可靠方式：

方式一：正则验证+显式转换（推荐）

先通过正则表达式过滤无效数字，再用TO_NUMBER显式转换：

-- 修复AMOUNT的case逻辑
case 
  when REGEXP_LIKE(AMOUNT, '^\d+(\.\d{1,2})?$') -- 验证是否为两位小数以内的有效数字
       AND TO_NUMBER(AMOUNT) < 1 
  then trim(to_char(TO_NUMBER(AMOUNT),'0.99')) 
  else trim(to_char(TO_NUMBER(AMOUNT),'99999999999.99')) 
end

方式二：统一字符串格式比较（适合数据格式规范的场景）

如果你的AMOUNT/ACCRUAL都是标准的数字字符串（无多余空格、格式统一），可以把比较的数字转为对应格式的字符串：

-- 修复ACCRUAL的case逻辑
case when ACCRUAL <> '0.00' -- 匹配你的数字字符串格式
  then xmlelement("ftc:Payment", xmlelement("ftc:Type",'FATCA502'), xmlelement("ftc:PaymentAmnt",xmlattributes(CCY as "currCode"), case when TO_NUMBER(ACCRUAL) < 1 then trim(to_char(TO_NUMBER(ACCRUAL),'0.99')) else trim(to_char(TO_NUMBER(ACCRUAL),'99999999999.99')) end)) 
end

2. 快速定位无效数据的方法 #

你可以先排查出触发错误的具体数据行，方便后续清理或过滤：

-- 找出AMOUNT中无法转为数字的行
SELECT AMOUNT, CUSTOMER_NO
FROM F_2019
WHERE NOT REGEXP_LIKE(AMOUNT, '^\d+(\.\d{1,2})?$');

-- 找出ACCRUAL中无法转为数字的行
SELECT ACCRUAL, CUSTOMER_NO
FROM F_2019
WHERE NOT REGEXP_LIKE(ACCRUAL, '^\d+(\.\d{1,2})?$');

这些查询会帮你定位到包含非数字字符的行，你可以先清理这些数据，或者在主查询的WHERE子句中过滤掉它们。

3. 日期转换的潜在风险补充 #

虽然当前错误是ORA-01722，但查询中TO_DATE(DATE_OF_BIRTH,'MM/DD/YYYY')也存在隐式转换风险——如果DATE_OF_BIRTH列有不符合MM/DD/YYYY格式的字符串，后续可能触发其他转换错误，建议同样添加验证：

case 
  when REGEXP_LIKE(DATE_OF_BIRTH, '^\d{2}/\d{2}/\d{4}$')
  then to_char(TO_DATE(DATE_OF_BIRTH,'MM/DD/YYYY'),'YYYY-MM-DD')
  else '' -- 或者设置无效日期的默认值
end

内容的提问来源于stack exchange，提问作者Lira