Oracle EBS OAF扩展如何强制VARCHAR列统一日期存储格式

当前故障由三层问题叠加导致：

• 存储设计存在先天缺陷：使用VARCHAR类型字段存储日期值，未在入库链路设置统一格式校验，页面回显的格式化字符串可直接写入表中，最终出现两种日期格式混杂的脏数据
• 透传传参逻辑无格式管控：现有代码直接调用setString将VO属性值透传到存储过程，首次保存时日历控件返回ISO标准YYYY-MM-DD格式值，第二次及以后保存时页面预填充的是展示用MM/DD/YYYY格式值，透传后直接把展示格式写入数据库
• 查询转换逻辑存在bug：现有查询中TO_DATE的格式掩码与实际存储值不匹配，2022-05-22为横杠分隔的YYYY-MM-DD格式，使用'YYYY/MM/DD'斜杠掩码做转换本身就会抛出格式错误，和二次保存的格式问题叠加后直接导致查询失败。

核心思路是在入库链路做强制格式归一，无论前端传入什么格式的日期字符串，最终写入VARCHAR列的值必须统一为YYYY-MM-DD格式，建议两层同时加校验，避免单点失效。

Java端逻辑调整（源头管控，优先实现） #

取消原有直接透传VO属性的传参方式，在给存储过程赋值前统一做格式解析和标准化：

// 日期格式标准化工具方法，所有传入存储过程的日期值都经过该方法处理
private String formatDateForStorage(String rawDateStr) {
    if (rawDateStr == null || rawDateStr.trim().isEmpty()) {
        return null;
    }
    SimpleDateFormat storageFormat = new SimpleDateFormat("yyyy-MM-dd");
    storageFormat.setLenient(false);
    // 兼容当前系统存在的两种输入格式
    SimpleDateFormat[] supportedFormats = new SimpleDateFormat[]{
        new SimpleDateFormat("yyyy-MM-dd"),
        new SimpleDateFormat("MM/dd/yyyy")
    };
    for (SimpleDateFormat format : supportedFormats) {
        format.setLenient(false);
        try {
            Date parsedDate = format.parse(rawDateStr.trim());
            return storageFormat.format(parsedDate);
        } catch (ParseException e) {
            // 格式不匹配则尝试下一个支持的格式
            continue;
        }
    }
    // 所有格式都不匹配时抛出业务异常，阻止脏数据入库
    throw new OAException("日期格式不合法，请重新通过日历选择器选择日期", OAException.ERROR);
}

// 替换原有传参逻辑
Object attr1 = busClassVORowImpl.getAttribute1();
Object attr2 = busClassVORowImpl.getAttribute2();
DBUtil.setString((OraclePreparedStatement)oracleCallableStatement, b1++, formatDateForStorage(attr1 == null ? null : attr1.toString()));
DBUtil.setString((OraclePreparedStatement)oracleCallableStatement, b1++, formatDateForStorage(attr2 == null ? null : attr2.toString()));

PL/SQL端逻辑调整（兜底校验，必须实现） #

在存储过程内增加一层日期格式归一逻辑，即使其他调用入口传入非标准格式日期，也能在入库前完成标准化，彻底避免脏数据写入：

-- 存储过程内复用的日期标准化函数
FUNCTION normalize_date_value(p_raw_date VARCHAR2) RETURN VARCHAR2 IS
    v_parsed_date DATE;
BEGIN
    IF p_raw_date IS NULL THEN
        RETURN NULL;
    END IF;
    -- 按优先级匹配支持的输入格式
    BEGIN
        v_parsed_date := TO_DATE(p_raw_date, 'YYYY-MM-DD');
    EXCEPTION WHEN OTHERS THEN
        BEGIN
            v_parsed_date := TO_DATE(p_raw_date, 'MM/DD/YYYY');
        EXCEPTION WHEN OTHERS THEN
            RAISE_APPLICATION_ERROR(-20001, '日期格式非法，仅支持YYYY-MM-DD、MM/DD/YYYY两种格式');
        END;
    END;
    -- 统一返回存储要求的标准格式
    RETURN TO_CHAR(v_parsed_date, 'YYYY-MM-DD');
END normalize_date_value;

-- 表更新逻辑中调用标准化函数
UPDATE ebs_ext_date_table
SET user_date1 = normalize_date_value(p_input_attr1),
    user_date2 = normalize_date_value(p_input_attr2)
WHERE row_id = p_record_id;

修正现有查询语句的格式掩码，保证TO_DATE的掩码与存储的YYYY-MM-DD格式完全匹配，修正后写法：

SELECT TO_CHAR(TO_DATE(stored_date_col, 'YYYY-MM-DD'), 'MM/DD/YYYY') AS display_date
FROM dual;

长期优化建议：如果后续有调整扩展表结构的权限，建议将这两个VARCHAR类型的日期字段改为DATE原生类型，从数据库层面彻底杜绝格式非法的脏数据，所有日期格式化逻辑全部下沉到页面展示层处理，不要在存储层保留格式转换逻辑。

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