Загадка рабочего разбитого запроса

Я пережил какой-то старый код, написанный в прошлом другим разработчиком в моей организации. При попытке улучшить этот код я обнаружил, что запрос, который он использовал, имел очень плохую проблему.

  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.

Странная вещь?

Этот код работает.

Сетка привязывается успешно. (Он не пытается привязываться к этому полю.) И он был в производстве в течение многих лет.

Итак, мой вопрос... почему? Я никогда не видел плохую работу запроса. Я никогда не видел, чтобы Oracle позволял ему или поставщику данных взломать его.

Кто-нибудь знает, что здесь происходит?

Ответы

Ответ 1

Хммм... Несколько вещей, чтобы проверить:

  • Выполняется ли этот код? Может показаться глупым предложить это, но может быть более новый файл, который заменил бы этот.

  • Является ли исключение из-за вашего кода? (Любой, кто назвал бы такие столбцы, определенно способен подавить эти отвратительные исключения)

  • Исключено ли исключение из стороннего кода? (Не так вероятно, но иногда сторонний код предпочитает использовать раздражающие коды ошибок вместо исключений).

Прошлые эти предложения, я не уверен.

EDIT:

Пересмотр второй точки, если вы работаете в ASP.NET, убедитесь, что не существует обработчика исключений на глобальном уровне, который исключает исключение. Я столкнулся с этой проблемой на одном сайте, над которым работал, и обнаружил десятки исключений за один день.

Ответ 2

Попробуйте запустить

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

вскоре после привязки сетки. Это скажет вам, действительно ли выражение было замечено Oracle. Обратите внимание, что вы должны видеть только указанный выше запрос, если он не был замечен Oracle.

Ответ 3

Используйте журнал трассировки ODBC, чтобы узнать, действительно ли этот запрос отправляется в базу данных, и посмотрите, какая база данных возвращается. Затем используйте любой другой инструмент базы данных на основе ODBC и проверьте, работает ли этот запрос с этого инструмента. В качестве окончательного теста вы можете написать простой Python script. Самый простой способ использовать ActiveState Python 2.x с включенным модулем odbc. Тестовый код может выглядеть так:

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

Если я понимаю, что пытался сделать оригинальный автор, и с помощью Banner, который никогда не бывает легко найти, этот запрос должен быть правильным:

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 из теста. Я отделил его от отражателя и нашел, к моему смущению, что вопрос прав. Это имеет смысл.

Я все еще не могу понять, почему у моей рабочей копии было одно неверное имя_поля. Насколько мне известно, до этой недели я никогда не касался этого файла. Но SVN не имеет истории, показывающей эту ошибку в предыдущих версиях.

Так странно... может быть, я схожу с ума.

Спасибо за всю качественную обратную связь по этому вопросу. Я, конечно, узнал о некоторых новых методах съемки стрельбы, и за это я очень благодарен.:)

Счастливое кодирование, Клиф