Логика работы ADO-компонентов

← →
Сергей М. © (2007-03-14 15:31) [0]

Некий ADODataSet ориентирован на открытие НД с использованием Microsoft.Jet.OLEDB.4.0 и ISAM=dBase IV

1. Активация компонента при условиях

CommandText = "SELECT * Table"
Filter = Field LIKE " XX*"
Filtered = TRUE

возвращает заведомо ожидаемый непустой НД.

2. Активация компонента при

CommandText = SELECT * Table WHERE Field LIKE " XX*"
Filtered = FALSE

возвращает заведомо ожидаемый пустой НД.

Где засада ?
Ткните, пож., носом ..
Оекружение/конфигурацию готов уточнить

← →
Сергей М. © (2007-03-14 15:33) [1]

> 2. Активация компонента при
>
> CommandText = SELECT * Table WHERE Field LIKE " XX*"
> Filtered = FALSE
>
> возвращает заведомо ожидаемый пустой НД.

Пардон, это ляп.

Читать - "Заведомо НЕожидаемый пустой НД"

← →
Johnmen © (2007-03-14 15:36) [2]

Где-то используется *, а где-то %
Для SQL стандартом считается именно %

← →
Сергей М. © (2007-03-14 15:45) [3]

> Johnmen © (14.03.07 15:36) [2]

"Где-то" это где ?

Я заменил шаблон * на % - та же самая печальная ситуация)

Да дело даже не в символе-шаблоне, как видно ..

← →
Сергей М. © (2007-03-14 15:48) [4]

результаты

SELECT ... WHERE Field LIKE " XX*"
SELECT ... WHERE Field LIKE " XX%"

одинаковы - НД как был пуст , так и им остался

← →
Сергей М. © (2007-03-14 15:52) [5]

А не следует ли мне проанализировать трассировку запросов, формируемых средствами ADO ?

Если есть резон, то чем лучше/удобней/дешевле/надежней ?

← →
Johnmen © (2007-03-14 16:04) [6]

> Сергей М. © (14.03.07 15:45) [3]
> Я заменил шаблон * на % - та же самая печальная ситуация)Да дело даже
> не в символе-шаблоне, как видно ..

Если замена не помогла, вот только тогда и видно...
Один вопрос - какого типа Field?

← →
stud © (2007-03-14 16:06) [7]

Сергей М. © (14.03.07 15:31)
SELECT * Table WHERE Field LIKE " XX*"
так а выполнить этот запрос например в sqlexplorer или аналогичной оболочке?

← →
Johnmen © (2007-03-14 16:06) [8]

ещё вопрос - что значит "Активация компонента"
и почему в запросе нет FROM?

← →
Сергей М. © (2007-03-14 16:08) [9]

> какого типа Field?

Строкового, разумеется ..

И индекс (неуникальный) по полю имеется ...

Поле имеет вормат Char(8)

← →
Сергей М. © (2007-03-14 16:10) [10]

> Johnmen © (14.03.07 16:06) [8]
>
> ещё вопрос - что значит "Активация компонента"

Active <- True

> почему в запросе нет FROM?
>

Пардон, очепятка.

Разумеется он есть, иначе бы не было вопроса

← →
Сергей М. © (2007-03-14 16:12) [11]

> Johnmen

Все эксперименты, вызвавшие вопросы, проводятся в дизайн-тайм, "отсебячина" тут, сам понимаешь, минимальна

← →
Johnmen © (2007-03-14 16:41) [12]

> Сергей М. © (14.03.07 16:12) [11]

Понимаю...
Странно это всё. Очень странно....
А что в реале вместо XX?

← →
Сергей М. © (2007-03-14 17:00) [13]

> Johnmen © (14.03.07 16:41) [12]
> Странно это всё. Очень странно....
> А что в реале вместо XX?

В "реале", к примеру, 62 (да мало ли в Бразилии педров ?!)) ...)

А было б не странным - разве я постил бы этот "странный" вопрос ?)

По моей "дубовой" логике, установка мной св-ва Filtered = True должна обязывать упомянутый компонент добавлять в конец строки св-ва CommandText значение указанного мной св-ва Filter (с неявным префиксом WHERE), что, собственно, успешно интерпретируется, иначе бы я схлопотал соотв.ошибку.

← →
stud © (2007-03-14 17:33) [14]

так а разве при использовании св-ва фильтеред фильтрация происходит не на клиенте из полученого набора?

← →
sniknik © (2007-03-14 17:50) [15]

> установка мной св-ва Filtered = True должна обязывать упомянутый компонент добавлять в конец строки св-ва CommandText
логика ошибочна.
Filtered фильтрует уже полученный на клиента рекордсет, а то что в команде (CommandText) то выполняется сервером, ограничивает саму выборку.
и кстати, теоретически(!) может быть разница между синтаксисом в запросе и синтаксисом в фильтре. т.к. это разные вещи. (т.е. в одном случае может быть * в другом %, в одних и тех же компанентах... )

← →
Anatoly Podgoretsky © (2007-03-14 19:23) [16]

> Сергей М. (14.03.2007 15:31:00) [0]

Вероятно интерпритатор запроса выбрасывает пробелы в начале строки

← →
sniknik © (2007-03-14 19:37) [17]

> Вероятно интерпритатор запроса выбрасывает пробелы в начале строки
я бы сказал наоборот, интерпретатор фильтра (никогда не сталкивался с такой подлостью в запросах... а фильтрами не так часто пользуюсь, мог пропустить), но в принципе и то и возможно (есть путаница в вопросе в одном, вполне и в другом возможна. хотя если принять, что поведение в вопросе описано верно то да, запрос виноват).

← →
Сергей М. © (2007-03-15 08:37) [18]

> sniknik © (14.03.07 17:50) [15]

> логика ошибочна

Принял к сведению.

> Anatoly Podgoretsky © (14.03.07 19:23) [16]

Я в общем-то тоже склоняюсь к версии, что интерпретатор каким-то образом модифицирует строку в LIKE-выражении, но каким и почему ? Что, по его разумению, "криминального" в строке с одним или более лидирующих пробелов ?

В ходе экспериментов я обнаружил еще один пока непонятный мне "фокус" - при WHERE Field = "что угодно, включая пустую строку" компонент дает отлуп с диагностикой "Индекс не найден", хотя индексный файл для этой таблицы заведомо существует в той же директории и индекс по полю Field в нем заведомо существует...

← →
Сергей М. © (2007-03-15 08:44) [19]

Я понял в чем дело - ISAM dBase IV не работает с CDX-индексами, а именно они фигурируют для сабжевой таблицы.

Как же поступить в этой ситуации ? Наведите на мысль ..

← →
Сергей М. © (2007-03-15 08:51) [20]

Все, сам сообразил)
Нужно использовать "родной" для этой таблицы ISAM FoxPro 2.x
Подозреваю, что ноги у проблемы с LIKE растут оттуда же.

← →
sniknik © (2007-03-15 08:51) [21]

сделать MDX индексы... CDX это от foxpro.

← →
sniknik © (2007-03-15 08:57) [22]

> Нужно использовать "родной" для этой таблицы ISAM FoxPro 2.x
он у тебя есть????
это же старый исам, еще от Jet 3.5 (там был официально), в Jet 4.0 все объеденили под одной маркой dBase (на самом деле убрали поддержку, официально по крайней мере. т.е. работает но... точно также как и BDE (а раз jet его использует...)).

← →
Сергей М. © (2007-03-15 11:17) [23]

> sniknik © (15.03.07 08:51) [21]

Да, таблица сверстана в FoxPro 2.5.
Cоздавать MDX не имеет смысла - ДОС-софт, постоянно работатающий с этой таблицей, оперирует только CDX"ом, и мне при открытии НД средствами ADO нужно задействовать именно этот индексный файл.

> это же старый исам, еще от Jet 3.5

Я в курсе. Но выбора у меня пока нет. Jet 4.0 OLEDB - провайдер напрямую работает только с dBASE ISAM, а для коннекта к нужной фоксовой таблице MS вынуждает использовать провайдера OLEDB for ODBC + собственно MS FoxPro ODBC-драйвер. Одновременная же работа с таблицей со стороны фоксового ДОС-драйвера и ODBC-драйвера чревата как минимум бесконечными падениями индексов (прецедентов на эту тему достаточно) в условиях, когда таблица лежит в шаре на сетевом файл-сервере.

Вот был бы Jet 3.5 OLEDB вот тогда, наверно, проблема сама собой рассосалась ..

← →
sniknik © (2007-03-15 11:56) [24]

> Вот был бы Jet 3.5 OLEDB вот тогда, наверно, проблема сама собой рассосалась ..
другие бы придумал, да и это у тебя не проблема, а желание использовать не то что есть, а то что хочется. (ну если на самом деле отсекает пробелы(до сих пор сомневаюсь)... ну неужто нельзя запрос по другому построить?)

и кстати, CDX индексы используются, пусть ограничено в чемто, но... если у тебя они не работают значит признак индексированности в таблице снят, а досовый фокс на него плюет, там можно указать использовать любой файл индекса при открытии.
и потом если индекс не работает то будет просто сканирование таблицы, на результат выборки влиять не должно. другое дело индекс всетаки пользуется но он сделан по выражению (типа LTRIM(Field)) которое Jet/BDE не понимает(предположительно. на самом деле кто его знает), воспринимает как целое поле... тогда пробелы вначале выражения у like просто лишние. ну типа того. домыслы без возможности проверить можно строить разные.

← →
Сергей М. © (2007-03-15 12:07) [25]

Спасибо всем, решение найдено - MS VFP OLEDB решил все упомянутые проблемы.

> Сергей М. (15.03.2007 12:07:25) [25]

Так и не хрен работать с ФоксПро таблицами, прямо или косвенно через БДЕ, поскольку последний почти не поддерживает ФоксПро, только на уровне декларации, когда формат совпадает с dBase IV

> А причем тут БДЕ ?
BDE jet-ом используется неявно для некоторых исамов... либо установленная, нормальная версия, либо урезанная включенная в установку jet-а.
что именно используется зависит от настроек и естественно присутствия первого (сколько ни ставь использовать установленный BDE, если он не установлен... по умолчанию выбирается автоматом).
ограничения одного действуют и на другого, раз уж используется. см [22]

> sniknik © (16.03.07 08:42) [28]

Да не интересует меня БДЕ !)

Я уже понял, что полноценный ISAM-доступ к фоксовым источникам через Jet 4.0 невозможен - MS при этом вынуждает пользовать FoxPro ODBC либо отказаться от Jet 4.0 в пользу Jet 3.5, где имеется нормальная ISAM-поддержка этих источников.
Но поскольку MSJETOLEDB35 (именно он по такой логике решил бы проблемы) днем с огнем не найти, приходится пользовать MSVFPOLEDB, что, впрочем, даже еще лучше - тут никакими Jet"ами и ISAM"мами не пахнет, предоставляется нативный и вполне корректный доступ к фоксовым источникам.

> предоставляется нативный и вполне корректный доступ к фоксовым источникам.
ну да, ну да... а попробуйка с этим найтивным и коректным источником индекс создать... (неважно что он тебе не нужен, только для чтения используешь. это в общем)
есть и другие мелкие отличия/несуразности (счас просто не вспомню).

у каждого есть свои недостатки/достоинства...

а, еще вспомнил. создание таблиц, есть нюансы типа если коннект настроен на один путь ну типа "C:\Foxpro\DB\" то создание таблицы вовсе не вовсе не гарантирует что она создастся в указанной папке... типа база тут и ни причем. ;о) приходится путь указывать явно в запросе. (а ну как используется ODBC DSN и в явном виду пути базы программа не знает? проблема на ровном месте...)

> sniknik © (16.03.07 10:34) [30]

> попробуйка с этим найтивным и коректным источником индекс
> создать

Мне оно действительно не нужно, но впрочем из любопытства попробую.

> только для чтения используешь

Нет, не только для чтения, но и для создания/удаления/модификации записей.
Уже проверил - существующие индексы вполне корректно обновляются, хотя время "глюки" рано или поздно покажет.

> есть и другие мелкие отличия/несуразности

По сравнению с Jet-геморроем для моих задач они действительно мелкие)

> По сравнению с Jet-геморроем для моих задач они действительно мелкие)
см. [26], как сказал Anatoly Podgoretsky "так и не хрен пользовать"...
работаешь с Foxpro через dBase драйвер так и "получи фашист гранату", тоже самое будет (а то и хуже) если Foxrpo-шным открыть dBase таблицы (только не старые где отличий и нет вообще, а поновее).

> А причем тут БДЕ ?

При том, что ISAM xBase использует БДЕ

> Я уже понял, что полноценный ISAM-доступ к фоксовым источникам
> через Jet 4.0 невозможен

Не возможен, ISAM только через БДЕ, к нему относятся Paradox, DBase и TextFiles
Для ФоксПро нужен OLE DB драйвер ФоксПро

> sniknik (16.03.2007 11:11:33) [33]

А фиг он сможет открыть dBase VII и выше

Логика работы ADO-компонентов Найти похожие ветки