![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Логика работы ADO-компонентов [D7, dBase, FoxPro]
Сергей М. © (2007-03-14 15:31:00)Некий 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
возвращает заведомо ожидаемый пустой НД.
Где засада ?
Ткните, пож., носом ..
Оекружение/конфигурацию готов уточнить
Anatoly Podgoretsky (2007-03-16 19:04:00) [1]> sniknik (16.03.2007 11:11:33) [33]
А фиг он сможет открыть dBase VII и выше
Anatoly Podgoretsky (2007-03-16 19:01:00) [2]
> Я уже понял, что полноценный ISAM-доступ к фоксовым источникам
> через Jet 4.0 невозможен
Не возможен, ISAM только через БДЕ, к нему относятся Paradox, DBase и TextFiles
Для ФоксПро нужен OLE DB драйвер ФоксПро
Anatoly Podgoretsky (2007-03-16 18:59:00) [3]
> А причем тут БДЕ ?
При том, что ISAM xBase использует БДЕ
sniknik (2007-03-16 11:11:00) [4]> По сравнению с Jet-геморроем для моих задач они действительно мелкие)
см. [26], как сказал Anatoly Podgoretsky "так и не хрен пользовать"...
работаешь с Foxpro через dBase драйвер так и "получи фашист гранату", тоже самое будет (а то и хуже) если Foxrpo-шным открыть dBase таблицы (только не старые где отличий и нет вообще, а поновее).
Сергей М. (2007-03-16 10:50:00) [5]
> sniknik © (16.03.07 10:34) [30]
> попробуйка с этим найтивным и коректным источником индекс
> создать
Мне оно действительно не нужно, но впрочем из любопытства попробую.
> только для чтения используешь
Нет, не только для чтения, но и для создания/удаления/модификации записей.
Уже проверил - существующие индексы вполне корректно обновляются, хотя время "глюки" рано или поздно покажет.
> есть и другие мелкие отличия/несуразности
По сравнению с Jet-геморроем для моих задач они действительно мелкие)
sniknik (2007-03-16 10:38:00) [6]а, еще вспомнил. создание таблиц, есть нюансы типа если коннект настроен на один путь ну типа "C:\Foxpro\DB\" то создание таблицы вовсе не вовсе не гарантирует что она создастся в указанной папке... типа база тут и ни причем. ;о) приходится путь указывать явно в запросе. (а ну как используется ODBC DSN и в явном виду пути базы программа не знает? проблема на ровном месте...)
sniknik (2007-03-16 10:34:00) [7]> предоставляется нативный и вполне корректный доступ к фоксовым источникам.
ну да, ну да... а попробуйка с этим найтивным и коректным источником индекс создать... (неважно что он тебе не нужен, только для чтения используешь. это в общем)
есть и другие мелкие отличия/несуразности (счас просто не вспомню).
у каждого есть свои недостатки/достоинства...
Сергей М. (2007-03-16 09:17:00) [8]
> 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'мами не пахнет, предоставляется нативный и вполне корректный доступ к фоксовым источникам.
sniknik (2007-03-16 08:42:00) [9]> А причем тут БДЕ ?
BDE jet-ом используется неявно для некоторых исамов... либо установленная, нормальная версия, либо урезанная включенная в установку jet-а.
что именно используется зависит от настроек и естественно присутствия первого (сколько ни ставь использовать установленный BDE, если он не установлен... по умолчанию выбирается автоматом).
ограничения одного действуют и на другого, раз уж используется. см [22]
Сергей М. (2007-03-16 08:31:00) [10]
> Anatoly Podgoretsky © (15.03.07 19:14) [26]
А причем тут БДЕ ?
Речь идет искл-но об АДО + OLEDB
Anatoly Podgoretsky (2007-03-15 19:14:00) [11]> Сергей М. (15.03.2007 12:07:25) [25]
Так и не хрен работать с ФоксПро таблицами, прямо или косвенно через БДЕ, поскольку последний почти не поддерживает ФоксПро, только на уровне декларации, когда формат совпадает с dBase IV
Сергей М. (2007-03-15 12:07:00) [12]Спасибо всем, решение найдено - MS VFP OLEDB решил всеупомянутые проблемы.
sniknik (2007-03-15 11:56:00) [13]> Вот был бы Jet 3.5 OLEDB вот тогда, наверно, проблема сама собой рассосалась ..
другие бы придумал, да и это у тебя не проблема, а желание использовать не то что есть, а то что хочется. (ну если на самом деле отсекает пробелы(до сих пор сомневаюсь)... ну неужто нельзя запрос по другому построить?)
и кстати, CDX индексы используются, пусть ограничено в чемто, но... если у тебя они не работают значит признак индексированности в таблице снят, а досовый фокс на него плюет, там можно указать использовать любой файл индекса при открытии.
и потом если индекс не работает то будет просто сканирование таблицы, на результат выборки влиять не должно. другое дело индекс всетаки пользуется но он сделан по выражению (типа LTRIM(Field)) которое Jet/BDE не понимает(предположительно. на самом деле кто его знает), воспринимает как целое поле... тогда пробелы вначале выражения у like просто лишние. ну типа того. домыслы без возможности проверить можно строить разные.
Сергей М. (2007-03-15 11:17:00) [14]
> 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 08:57:00) [15]> Нужно использовать "родной" для этой таблицы ISAM FoxPro 2.x
он у тебя есть????
это же старый исам, еще от Jet 3.5 (там был официально), в Jet 4.0 все объеденили под одной маркой dBase (на самом деле убрали поддержку, официально по крайней мере. т.е. работает но... точно также как и BDE (а раз jet его использует...)).
sniknik (2007-03-15 08:51:00) [16]сделать MDX индексы... CDX это от foxpro.
Сергей М. (2007-03-15 08:51:00) [17]Все, сам сообразил)
Нужно использовать "родной" для этой таблицы ISAM FoxPro 2.x
Подозреваю, что ноги у проблемы с LIKE растут оттуда же.
Сергей М. (2007-03-15 08:44:00) [18]Я понял в чем дело - ISAM dBase IV не работает с CDX-индексами, а именно они фигурируют для сабжевой таблицы.
Как же поступить в этой ситуации ? Наведите на мысль ..
Сергей М. (2007-03-15 08:37:00) [19]
> sniknik © (14.03.07 17:50) [15]
> логика ошибочна
Принял к сведению.
> Anatoly Podgoretsky © (14.03.07 19:23) [16]
Я в общем-то тоже склоняюсь к версии, что интерпретатор каким-то образом модифицирует строку в LIKE-выражении, но каким и почему ? Что, по его разумению, "криминального" в строке с одним или более лидирующих пробелов ?
В ходе экспериментов я обнаружил еще один пока непонятный мне "фокус" - при WHERE Field ='что угодно, включая пустую строку' компонент дает отлуп с диагностикой 'Индекс не найден', хотя индексный файл для этой таблицы заведомо существует в той же директории и индекс по полю Field в нем заведомо существует...
sniknik (2007-03-14 19:37:00) [20]> Вероятно интерпритатор запроса выбрасывает пробелы в начале строки
я бы сказал наоборот, интерпретатор фильтра (никогда не сталкивался с такой подлостью в запросах... а фильтрами не так часто пользуюсь, мог пропустить), но в принципе и то и возможно (есть путаница в вопросе в одном, вполне и в другом возможна. хотя если принять, что поведение в вопросе описано верно то да, запрос виноват).