WPF调用Oracle函数报ORA-01843无效月份错误，SQL Developer执行正常

这个问题我之前碰到过好几次，ORA-01843本质是Oracle无法识别你传入的日期格式——虽然你在SQL Developer里执行正常，但WPF用OleDB调用时出问题，核心原因在于字符串拼接日期的方式不可靠，还容易受Oracle会话的NLS_DATE_FORMAT设置影响。

为什么会踩这个坑？ #

你现在把DateTime转成字符串再硬拼进SQL里，虽然用了InvariantCulture确保格式是MM/DD/YYYY HH24:MI:SS，但OleDB和Oracle建立会话时，默认的NLS_DATE_FORMAT可能和你指定的格式不匹配，导致Oracle解析TO_DATE时直接报错。而且这种硬拼接的方式还存在SQL注入风险，绝对不是最佳实践。

最稳妥的解决方案：用参数化查询 #

直接把DateTime对象作为参数传给SQL，让数据库驱动自己处理类型转换，完全避开字符串格式的坑。代码示例如下：

// 构造带参数占位符的SQL，不用手动拼接日期字符串
var getRateQry = "SELECT fn_get_rate(:pStartDate) DUMMY FROM DUAL";

using (var cmd = new OleDbCommand(getRateQry, yourOleDbConnection))
{
    // 添加日期参数，需要保留时分秒的话用OleDbType.DBTimeStamp
    var dateParam = cmd.Parameters.Add(":pStartDate", OleDbType.DBTimeStamp);
    dateParam.Value = implemStartDt;

    // 执行查询并处理结果
    using (var reader = cmd.ExecuteReader())
    {
        if (reader.Read())
        {
            // 读取返回值，比如 var rateResult = reader["DUMMY"];
        }
    }
}

额外补充（不推荐的临时方案） #

如果实在要沿用TO_DATE的写法，你可以在打开连接后先执行会话配置，强制Oracle使用你指定的日期格式：

ALTER SESSION SET NLS_DATE_FORMAT = 'MM/DD/YYYY HH24:MI:SS';
ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'MM/DD/YYYY HH24:MI:SS';

但这种方式不如参数化查询可靠——不同数据库会话可能有不同配置，而且依然存在SQL注入风险，所以还是优先用参数化的写法。

总的来说，参数化查询是解决这类日期格式问题最稳妥、最安全的方式，既能彻底避开ORA-01843错误，又能提升代码的安全性。

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