Access 2007 для связанной таблицы Oracle 10g - запрос с ошибочными результатами, но без ошибок - PullRequest
Новая
       33

Access 2007 для связанной таблицы Oracle 10g - запрос с ошибочными результатами, но без ошибок

0 голосов
/ 27 июля 2010

Базы данных Access 2007, запрашивающие связанные таблицы Oracle 10g, возвращают некорректные наборы результатов при использовании предложения WHERE для фильтрации нежелательных записей. Как ни странно, некоторая фильтрация происходит, но ненадежно.

Я могу достоверно продемонстрировать / создать проблему следующим образом:

  1. Создание * новой * базы данных с помощью Access 2007.
  2. Создайте вторую * новую * базу данных с Access 2007, а затем "save-as" 2000.
  3. Создайте третью * новую * базу данных со старой версией Access.
  4. Выполните следующий запрос в каждой базе данных: 
SELECT 
    STATUS, 
    ID, 
    LAST_NAME, 
    FIRST_NAME
FROM 
    Oracle10g_table
WHERE 
        STATUS="A"
  • В обеих базах данных, созданных с помощью Access 2007, выполнение этого запроса даст вам набор результатов, в котором некоторые записей, где (STATUS = "A") = false были отфильтрованы, но не все из них.
  • В базах данных, созданных с более ранними версиями доступа, предложение where фильтруется правильно, а набор результатов является правильным.
  • STATUS - текстовое поле
  • Таблица является «связанной» таблицей с базой данных Oracle10g
  • Таблица содержит 68 тыс. Строк
  • Я проверил тайм-аут в 60, 1000 и 0

Кто-нибудь сталкивался с этой проблемой?

Интересно, будет ли это новая «функция» доступа, которая также повлияет на 2010 год. Может ли это быть как-то связано с ODBC?

Спасибо за любую помощь, - Дэйв

ПОДРОБНЕЕ ...

Я только что попробовал альтернативную форму запроса, используя HAVING вместо WHERE, и это сработало! Проблема в том, что кроме того, что это ничего не должно изменить (да - больше виртуальных таблиц, но не должно изменять конечный результат), мои конечные пользователи будут использовать визуальный конструктор запросов Access 2007, а не вводить SQL напрямую, что происходит по умолчанию любые критерии, которые они вводят в ГДЕ.

Ответы [ 3 ]

1 голос
/ 11 августа 2010

У меня была похожая проблема. В моем случае изменение драйвера ODBC сработало, но я также мог бы просто изменить «уникальный идентификатор записи» на столбец без нуля. Это не обязательно должен быть «правильный» уникальный идентификатор записи.

1 голос
/ 27 июля 2010

Я догадываюсь, что один из ваших драйверов ODBC, используемый Access для подключения к Oracle, рассматривает «A» как имя столбца, а не как «A».Вы пробовали одинарные кавычки на букву «А»?В Oracle двойные кавычки используются для ссылки на имена столбцов, есть ли случайно столбец с именем «A»?

Пример запроса Oracle # 1 

Select object_name from all_objects
where "OBJECT_NAME" = 'DUAL'

Пример запроса Oracle # 2 

with example as (
Select object_name as "Fancy Column Name" from all_objects
)
select * from example
where "Fancy Column Name" = 'DUAL'
0 голосов
/ 28 июля 2010

Оказалось, что это проблема, связанная с ODBC. Наш отдел технической поддержки устанавливает соединение на каждой из наших рабочих станций - они сами программируют это, и кто знает, что они на самом деле вкладывают в него, - но в итоге получается, что при соединении с источником данных ODBC с помощью Access (любой версии) наши сетевые серверы отображаются на вкладке «источник данных о машине», поэтому мы просто нажимаем на тот, который нам нужен, и мы уходим. Это работало хорошо до Access 2007.

Я создал «новый» источник машинных данных, который позволял мне сам выбирать драйвер ODBC (вместо того, чтобы заставлять меня использовать тот, который создали наши сотрудники технической поддержки). Я выбрал «Microsoft ODBC для Oracle», ввел имя сервера, который хотел, и это все, что потребовалось. Теперь проблема несогласованной фильтрации предложения WHERE решена (я надеюсь).

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

...