【问题标题】:Business Objects Webi error IES 10811 with custom SQL带有自定义 SQL 的业务对象 Webi 错误 IES 10811
【发布时间】:2016-05-12 13:29:36
【问题描述】:

我们正在使用从标准 Epic 发布的 Universe 修改的 Universe 发布的 WEBI,并且必须对 WEBI 背后的 SQL 代码进行一些小的更改

加入的字段仍然是相同的数据类型,并且 SELECT 或 WHERE 子句中的字段都没有更改,但由于某种原因,当我们按下验证按钮时,我们会收到此错误代码 'The data type of a column in the查询无效。 (IES 10811)'

有人对我还可以解决哪些问题有什么建议吗?提前致谢!

修改后的代码使用一个名为 CLARITY_SER_2 的具有完全相同数据结构的表为 X_CLARITY_SER 别名

内部连接 ​​CLARITY_SER_2 X_CLARITY_SER_800 开启 >(V_LOG_BASED.PRIMARY_PHYSICIAN_ID=X_CLARITY_SER_800.PROV_ID) 左外连接 ZC_PAT_SERVICE ON (X_CLARITY_SER_800.SERVICE_DEFAULT_C=ZC_PAT_SERVICE.HOSP_SERV_C)

原始代码

INNER JOIN X_CLARITY_SER_800 ON (V_LOG_BASED.PRIMARY_PHYSICIAN_ID=X_CLARITY_SER_800.PROV_ID) INNER JOIN ZC_PAT_SERVICE ON (X_CLARITY_SER_800.SERVICE_DEFAULT_C=ZC_PAT_SERVICE.HOSP_SERV_C)

【问题讨论】:

    标签: business-objects


    【解决方案1】:

    错误意味着其中一个 Universe 对象的数据类型与数据库列的数据类型不匹配。 不应该在您的情况下发生,在这种情况下,您将更改为具有相同结构的另一个表。我想知道宇宙中的一个对象是否有不正确的数据类型——也就是说,无论您的 SQL 更改如何,问题都存在,但它只是在尝试解析 SQL 时注意到了问题。

    我会在宇宙中进行完整性检查。这将识别任何不正确的数据类型。我假设您已经仔细检查了两个表确实具有相同的结构,但可能值得再次检查。

    最后,作为一种蛮力调试方法,我将开始从查询(以及 SQL 中的关联列)中删除对象以找到导致问题的对象。

    【讨论】:

      【解决方案2】:

      对我来说,解决方案是在 Universe 设计器中刷新源表。 BO 以错误的方式选择了带有日期的列类型(作为字符列),这就是我的新表的列类型不匹配的原因。

      编辑: 当我想发送带有 BO 发布的电子邮件时,我遇到了诸如映射数据库中的 varchar 列与 BO 中的 date 列以及错误 "Unexpected behavior" (IES 10901) (FBE60502) 之类的问题。

      【讨论】:

        猜你喜欢
        • 2021-09-07
        • 1970-01-01
        • 1970-01-01
        • 2019-04-09
        • 2014-03-05
        • 2017-02-28
        • 2011-07-23
        • 2011-12-05
        • 1970-01-01
        相关资源
        最近更新 更多