c# - ODP.NET : Parameter Types "cached" on identical CommandText

Question

我目前正在评估 Oracle 的 ODP.NET DataProvider，我遇到了一个在我们的测试用例中弹出的问题:当使用不同的参数类型执行相同的命令文本时，使用第一个执行命令的参数类型在以下所有命令中。

以下面的代码为例:

const int sampleInt32 = 1234567890;
const string sampleNvarchar = "someTestString";

const string sqlCommandtext = "SELECT :PARAM PARAM FROM DUAL";
using (OracleConnection connection = new OracleConnection(builder.ConnectionString))
{
    connection.Open();

    //Test 1 - Int 32
    using (OracleCommand commandInt32 = connection.CreateCommand())
    {
        commandInt32.CommandText = sqlCommandtext;
        commandInt32.Parameters.Add("PARAM", OracleDbType.Int32, sampleInt32, ParameterDirection.Input);
        using (IDataReader reader = commandInt32.ExecuteReader())
        {
            while (reader.Read())
            {
                int resultInt32 = (int)reader.GetDecimal(0);
                Assert.AreEqual(sampleInt32, resultInt32);
            }
        }
    }
    //Test 2 - NVarchar
    using (OracleCommand commandNVarchar = connection.CreateCommand())
    {
        commandNVarchar.CommandText = sqlCommandtext;
        commandNVarchar.Parameters.Add("PARAM", OracleDbType.NVarchar2, sampleNvarchar, ParameterDirection.Input);
        using (IDataReader reader = commandNVarchar.ExecuteReader())
        {
            while (reader.Read())
            {
                string resultNVarchar = reader.GetString(0);
                Assert.AreEqual(sampleNvarchar, resultNVarchar);
            }
        }
    }
}

如果 commandInt32 在 commandNVarchar 之前执行，则 commandNVarchar 的执行会失败并显示 ORA-01722 - 无效数字。如果顺序转换为先执行 commandNVarchar，则它会在 reader.GetDecimal 上失败并显示“指定的转换无效”。

到目前为止，我已经尝试设置 StatementCacheSize=0；池化=假； StatementCachePurge=true 作为 ConnectionString 参数，但我无法让它工作。

有什么我遗漏的吗？还有其他值得尝试的选择吗？

编辑:也许一些关于为什么需要/要求的背景:我们不直接在我们的应用程序中使用 ODP 或任何其他数据提供者(或者至少:我们正在努力达到这个目标)，中间有一个 DataLayer 执行数据库/提供程序特定的优化和连接健康的监控，......

在这一层中，例如可以调用 StoredProcedures，具有参数类型调整的选项。我们的一些程序将 Clob 作为参数类型，因为有时值可能比 x 个字符长，但很可能会更短。因此，在通过将 ArrayBindCount 设置为 y 的 ExecuteNonQuery 执行之前，将检查参数值是否可以将 Clob 作为 varchar 传递(Nclob 作为 Nvarchar)。 “重新绑定(bind)”将执行 2500 条记录的时间从大约 500 毫秒减少到 200 毫秒，代价是损失了几毫秒检查字符串长度。并且只有在可以更改参数类型的情况下才能进行此重新绑定(bind)。如果没有此选项，我们将需要每次都将其作为 Clob 执行，从而影响性能。

Answer 1

据我了解，SELECT 列表不支持参数绑定(bind)。令我惊讶的是，这一切都有效，以至于我不得不运行您的代码才能亲眼看到它。我认为客户端允许执行该 SQL 语句根本就是一个错误。

无论如何，我在测试用例之间插入了以下行以使它们都能正常工作:

connection.PurgeStatementCache();

但是，这似乎只适用于托管客户端(我已经在 4.112.3.60 版中尝试过)。正如您所描述的那样，普通客户端仍然会失败。