【问题标题】:The riddle of the working broken query工作中断查询之谜
【发布时间】:2011-04-30 21:08:52
【问题描述】:

我正在浏览一些旧代码,这些旧代码是由我所在组织的另一位开发人员在几年前编写的。在尝试改进此代码时,我发现它使用的查询有一个非常糟糕的问题。

  OdbcDataAdapter financialAidDocsQuery =
            new OdbcDataAdapter(
                @"SELECT   a.RRRAREQ_TREQ_CODE, 
                           b.RTVTREQ_SHORT_DESC, 
                           a.RRRAREQ_TRST_DESC, 
                           RRRAREQ_STAT_DATE,
                           RRRAREQ_EST_DATE,
                           a.RRRAREQ_SAT_IND, 
                           a.RRRAREQ_SBGI_CODE, 
                           b.RTVTREQ_PERK_MPN_FLAG, 
                           b.RTVTREQ_PCKG_IND, 
                           a.RRRAREQ_MEMO_IND,
                           a.RRRAREQ_TRK_LTR_IND, 
                           a.RRRAREQ_DISB_IND, 
                           a.RRRAREQ_FUND_CODE, 
                           a.RRRAREQ_SYS_IND
                  FROM     FAISMGR.RRRAREQ a, FAISMGR.RTVTREQ b
                  WHERE    a.RRRAREQ_TREQ_CODE = b.RTVTREQ_CODE
                           and a.RRRAREQ_PIDM = :PIDM
                           AND a.RRRAREQ_AIDY_CODE = :AidYear ",
                this.bannerOracle);
        financialAidDocsQuery.SelectCommand.Parameters.Add(":PIDM", OdbcType.Int, 32).Value = this.pidm;
        financialAidDocsQuery.SelectCommand.Parameters.Add(":AidYear", OdbcType.Int, 32).Value = this.aidYear;
        DataTable financialAidDocsResults = new DataTable();
        financialAidDocsQuery.Fill(financialAidDocsResults);
        FADocsGridView.DataSource = financialAidDocsResults;
        FADocsGridView.DataBind();

问题是a.RRRAREQ_TRST_DESC 列不存在。在 Oracle SQL Developer 中运行它时,您会很快了解到这一点。

奇怪的事情?

此代码有效。

gridview 绑定成功。 (它不会试图绑定到那个领域。)而且它已经投入生产多年了。

那么,我的问题是……为什么?我从未见过糟糕的查询工作。我从未见过甲骨文允许它或数据提供者绕过它。

有人知道这里发生了什么吗?

【问题讨论】:

  • 奇怪... RRRAREQ_TRST_DESC 曾经存在过吗?
  • 那些列名让我头疼
  • 它是否会导致处理异常,而 else 正在执行有效的查询并绑定它?你确定它真的用过吗?不是没有实际引用的残留代码吗?
  • 您确定您是在正确的数据库或确实有该列的某个备份数据库上运行此查询吗?
  • 我和萨钦在一起。如果这段代码正在执行,那么我的查询没有命中你认为的数据库。

标签: c# sql oracle gridview odbc


【解决方案1】:

嗯...有几件事要检查:

  1. 这段代码真的可以运行吗?建议这样做可能看起来很愚蠢,但可能有一个更新的文件取代了这个。

  2. 您的代码是否压制了异常? (任何会像这样命名列的人肯定能够压制那些讨厌的异常)

  3. 异常是否被第 3 方代码压制? (不太可能,但有时第 3 方代码更喜欢使用烦人的错误代码而不是异常)。

过去那些建议,我不确定。

编辑:

回顾第二点,如果您在 ASP.NET 中工作,请检查是否没有抑制异常的全局级异常处理程序。我在我工作的一个网站上遇到了这个问题,一天之内就发现了几十个异常。

【讨论】:

  • 我很确定我的基础已涵盖在这 3 个计数上,因为我实际上可以在绑定到该表的 gridview 中看到数据。该代码虽然多年未更改,但已在我们的部署过程中多次推送,因此我相信它是相同的代码。 :)
  • 即使您可以看到表中的数据,您也不确定这是实际运行的查询。您是否尝试添加一个虚拟列“'SO' as Dummy”并查看它是否也出现在网格视图中?
  • 我对此表示赞赏,因为您正确地确定了问题在于我正在查看的代码不是正在运行的代码。
【解决方案2】:

尝试运行

select * from v$sql where sql_fulltext like '%a.RRRAREQ_TRST_DESC%'

绑定网格后不久。这将告诉您该语句是否被 Oracle 实际看到。请注意,只有在 Oracle 没有看到上述查询时,您才应该看到它。

【讨论】:

  • 同样,您可以使用 DBMS_MONITOR 运行跟踪并检查跟踪文件中的查询。
【解决方案3】:

使用 ODBC 跟踪日志查看此查询是否真的发送到数据库,并查看数据库返回什么。然后使用任何其他基于 ODBC 的数据库工具并检查此查询是否可以从此工具工作。作为终极测试,您可以编写简单的 Python 脚本。使用包含odbc 模块的ActiveState Python 2.x 的最简单方法。测试代码可能如下所示:

import odbc

connection = odbc.odbc('dnsname/user/password')
cursor = connection.cursor()
cursor.execute("select ...")
for row in cursor.fetchall():
    print '\t'.join([str(r) for r in row])

如果您的程序没有错误,而其他工具有错误,请比较他们的 ODBC 跟踪。

【讨论】:

    【解决方案4】:

    如果我理解原作者想要做什么,并且使用不容易弄清楚的横幅,那么这个查询应该是正确的:

    SELECT a.rrrareq_treq_code,
           b.rtvtreq_short_desc,
           c.rtvtrst_desc,
           rrrareq_stat_date,
           rrrareq_est_date,
           a.rrrareq_sat_ind,
           a.rrrareq_sbgi_code,
           b.rtvtreq_perk_mpn_flag,
           b.rtvtreq_pckg_ind,
           a.rrrareq_memo_ind,
           a.rrrareq_trk_ltr_ind,
           a.rrrareq_disb_ind,
           a.rrrareq_fund_code,
           a.rrrareq_sys_ind
    FROM   faismgr.rrrareq a,
           faismgr.rtvtreq b,
           faismgr.rtvtrst c
    WHERE  a.rrrareq_treq_code = b.rtvtreq_code
    AND    a.rrrareq_trst_code = c.rtvtrst_code
    AND    a.rrrareq_pidm = :PIDM
    AND    a.rrrareq_aidy_code = :AidYear;

    【讨论】:

      【解决方案5】:

      好吧,让我们把它归入误报类别。

      我决定让我们的增值税从测试中发送一份 DLL 副本。我用反光板把它拆开,发现这个问题是对的,这让我很尴尬。这是有道理的。

      我仍然无法弄清楚为什么我的工作副本会有一个不正确的 field_name。据我所知,在这周之前我从未接触过这个文件。但是,SVN 在以前的版本中没有任何显示此错误的历史记录。

      太奇怪了……也许我疯了。

      感谢您对这个问题的所有质量反馈。我当然学到了一些新的故障排除技术,对此我非常感激。 :)

      快乐编码, 克里夫

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2013-11-01
        • 2020-02-03
        • 1970-01-01
        • 1970-01-01
        • 2020-08-05
        • 1970-01-01
        • 2011-10-11
        相关资源
        最近更新 更多