0

我的（SAP IdM）应用程序中有以下 SQL 代码：

Select mcmskeyvalue as MKV,v1.searchvalue as STARTDATE, v2.avalue as Running_Changes_flag
from idmv_entry_simple 
inner join idmv_value_basic_active v1 on mskey = mcmskey and attrname = 'Start_of_company_change'
    and mcentrytype = 'MX_PERSON' and to_date(v1.searchvalue,'YYYY-MM-DD')<= sysdate+3
left join idmv_value_basic v2 on v2.mskey = mcmskey and v2.attrname = 'Running_Changes_flag'
where mcmskey not in (Select mskey from idmv_value_basic_active where attrname = 'Company_change_running_flag')

我已经找到了 ORA-01841 问题的解决方案，因为它可能是类似于此处提到的 MSSQL try_to_date 的解决方案：如何在 SELECT 语句中处理 to_date 异常以忽略这些行？
或者我将代码更改为这样的解决方案，以仅在字符串上工作：

Select mcmskeyvalue as MKV,v1.searchvalue as STARTDATE, v2.avalue as Running_Changes_flag
from idmv_entry_simple 
inner join idmv_value_basic_active v1 on mskey = mcmskey and attrname = 'Start_of_company_change'
    and mcentrytype = 'MX_PERSON' and v1.searchvalue<= to_char(sysdate+3,'YYYY-MM-DD')
left join idmv_value_basic v2 on v2.mskey = mcmskey and v2.attrname = 'Running_Changes_flag'
where mcmskey not in (Select mskey from idmv_value_basic_active where attrname = 'Company_change_running_flag')

因此，对于实际问题，我有一个解决方案。
但现在我开始与我的客户和队友讨论为什么会发生错误。
基本上对于符合“attrname = 'Start_of_company_change'”要求的 idmv_value_basic_activ 的所有条目，我们可以确定这些是日期。此外，如果我们执行查询以检查将要传递的所有值，则所有值都是有效格式。
我在大学里了解到，DB-Engine 可以决定以何种顺序运行查询的各个部分。所以对我来说，最合乎逻辑的解释是，在开发环境（我们面临问题的地方），“to_date(v1.searchvalue,'YYYY-MM-DD')<= sysdate+3”部分在section “attrname = 'Start_of_company_change'” 而在生产环境中，一切都像魅力一样工作，段按照 SQL 语句描述的顺序执行。
现在我的问题是：
首先：我记得对吗，因为老师说只有一次，当时我无法真正理解它
第二：我的这个假设是正确的还是有其他问题的原因？

边界信息：
该工具使用一种移位数据结构，这就是为什么在 idmv_value_basic_activ 视图的实际“搜索值”列中可以有很多不同类型的原因。数据库层的数据类型始终是 varchar 类型。

4

1 回答 1

3

“DB-Engine 可以决定以何种顺序运行查询的各个部分”

这是对的。SQL 查询只是对所需数据及其存储位置的描述。Oracle 将计算一个执行计划以尽可能地检索该数据。该计划将根据任何数量的因素而有所不同，例如表中的实际行数和索引的存在，因此它会因环境而异。

因此，听起来您的表格中某处的日期无效，因此to_date引发了异常。您可以使用validate_conversion它来找到它。

于 2021-11-24T04:20:32.993 回答