Oracle9i: выражение фильтра не может исключить данные во время выполнения

Question

У меня есть относительно простой оператор выбора в программе VB6, который я должен поддерживать. (Подавить вашу естественную склонность к содроганию; я унаследовал это, я не написал).

Утверждение простое (переформатировано для ясности):

select distinct 
   b.ip_address 
from 
   code_table a, 
   location b 
where 
   a.code_item = b.which_id and 
   a.location_type_code = '15' and 
   a.code_status = 'R'

Данная таблица возвращает список IP-адресов из базы данных. Ключевой столбец, о котором идет речь, - code_status. Некоторое время назад мы поняли, что один из IP-адресов больше не действителен, поэтому мы изменили его статус на I (недействительный), чтобы исключить его появление в результатах запроса.

Когда вы выполняете запрос выше в SQL Plus или в SQL Developer, все в порядке. Но когда вы выполняете его из VB6, проверка на code_status игнорируется, и в наборе результатов появляется неверный IP-адрес.

Моим первым предположением было то, что результаты были где-то кэшированы Но, не будучи экспертом Oracle, я понятия не имею, где искать.

Это древний код VB6. SQL встроен в приложение. На данный момент у меня нет времени переписать его как хранимую процедуру. (Мне когда-нибудь дадут возможность.) Но мне нужно знать, что вызвало бы это несоответствие в поведении и как его устранить. Если это происходит здесь, скорее всего, это происходит где-то еще.

Если кто-нибудь может предложить хорошее место, чтобы посмотреть, я был бы очень признателен.

Answer 1

Несколько случайных идей:

• Вы уверены, что вы зафиксировали изменения, которые делают недействительным IP-адрес? Может ли кто-то другой (используя другое соединение / пользователя БД) увидеть измененный код_стата?

• Вы уверены, что результаты не изменились после их возвращения из базы данных?

• Вы уверены, что используете в SQLPlus то же соединение с базой данных, что и в коде (база данных, пользователь и т. Д.)?

• Вы уверены, что это действительно SQL, отправленный в базу данных? (Вы можете проверить это путем трассировки на сервере Oracle или отладки кода VB). Переформатирование могло изменить «что-то».

Вдобавок ко всему, я не могу вспомнить ни одного «кеширования», которое могло бы «повторно вставить» нежелательный ip. Надеюсь, что-то из вышеперечисленного дает вам некоторые идеи о том, где смотреть.

Answer 2

Я бы посоветовал вам взглянуть на системное представление V $ SQL, чтобы убедиться, что запрос, который, по вашему мнению, выполняется кодом VB6, на самом деле является запросом, который он выполняет.

Что-то вроде

select sql_text, fetches
where sql_text like '%ip_address%'

Убедитесь, что SQL_TEXT - это то, что вы ожидаете, и что число FETCHES увеличивается при выполнении кода.

Answer 3

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

Это нигде не кешируется. Oracle не кэширует результаты до 11 и даже тогда знает, как изменить кэш, когда ответ может измениться.

Я думаю, это проблема с данными. У вас есть DISTINCT по IP-адресу в запросе, почему? Если уникальных ограничений нет, возможно, существует более одной копии вашего IP-адреса, и вы исправили только одну из них.

И ваш Code_status находится в совершенно другой таблице с вашими IP-адресами. Вы устанавливаете статус «I» в таблице кодов и получаете список IP-адресов из таблицы местоположений.

Перестань думать о зебрах и начни думать о лошадях. Это почти наверняка просто данные, которые вы не полностью понимаете.

Запустите это

select 
   a.location_type_code, 
   a.code_status 
from 
   code_table a, 
   location b 
where 
   a.code_item = b.which_id and 
   b.ip_address = <the one you think you fixed>

Могу поспорить, вы получите один ряд с 'I', а другой ряд с 'R'

Answer 4

В дополнение к предложениям IronGoofy, вы пытались обменяться двумя последними пунктами?

where
   a.code_item = b.wich_id and
   a.code_status = 'R' and
   a.location_type_code = '15'

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