ADO + mdb = низкая(?) скорость выборки

[Andrey Fedorov]

Действительно - попробовал сам - функции с MDB-шками действительно работают:

Дело не в MDB, а в Jet-провайдере. В документации об этом сказано, перечислены функции, которые поддерживаются.
LEN, TRIM, UCASE, LCASE и другие.

Да это понятно... Но не помню уже почему у меня отложилось что из VB6 они не работают - давно это было...

[iGrok]

Но не помню уже почему у меня отложилось что из VB6 они не работают - давно это было...

Скорей всего, не заработала какая-то ещё функция, которая самим Access поддерживается, а Jet-провайдером - нет.

[alibek]

Скорей всего, не заработала какая-то ещё функция, которая самим Access поддерживается, а Jet-провайдером - нет.

Например, IIf или NZ.

[SergT]

1. В данном контексте это функция на SQL, а Access.
2. Функции работают только если запрос выполняется из среды Access.
3. Приводить к верхнему регистру нафиг не нужно.

1, 2 - Давно пользуюсь подобным синтаксисом из VB, всегда работает. Кавычки тоже не проблема (Replace).
3. Очень нужно, так как записи, в моем случае, могут быть в разных регистрах.
например: [ИВАНОВ Иван Иванович] и [Иванов Иван Иванович] распознаются как разные записи!

А вот что вы думаете о задержках (см. название топика)?
Проблема так и осталась. Крутил, вертел индексы в таблицах - влияние конечно есть, но задержки появляются в других местах. Может действительно JET шалит? Переустановить что ли на всех компах?

[iGrok]

3. Очень нужно, так как записи, в моем случае, могут быть в разных регистрах.
например: [ИВАНОВ Иван Иванович] и [Иванов Иван Иванович] распознаются как разные записи!

Да что за ерунда..
Ну вбей обе записи в табличку и сделай выборку с where [field] = 'ИВАНОВ ИВАН ИВАНОВИЧ'. Выберутся ОБЕ записи.
Аналогично ведут себя почти все движки БД.

А насчёт тормозов - я уже писал, что работа с файловой БД по сети - весьма небыстра. И писал, что можно попробовать сделать - вытащить ВСЁ что нужно в рекордсет, и искать уже по нему при помощи Find / Filter.
Пробовал?

Да, разумеется, закрывать рекордсет после поиска не надо. Он должен висеть открытым всё то время, что он нужен в программе. Этот вариант, конечно, нехило жрёт память.. Но тормоза при работе с файловой бд мы в своё время победили только таким образом.
Ну а потом уже ушли с файловой на серверную..

[Andrey Fedorov]

3. Очень нужно, так как записи, в моем случае, могут быть в разных регистрах.
например: [ИВАНОВ Иван Иванович] и [Иванов Иван Иванович] распознаются как разные записи!

Да что за ерунда..
Ну вбей обе записи в табличку и сделай выборку с where [field] = 'ИВАНОВ ИВАН ИВАНОВИЧ'. Выберутся ОБЕ записи.
Аналогично ведут себя почти все движки БД.

Есть все-же вариант когда не выберутся - неверно установленный Collation базы данных. Но это надо постараться.

[SergT]

1. А насчёт тормозов - я уже писал, что работа с файловой БД по сети - весьма небыстра. И писал, что можно попробовать сделать - вытащить ВСЁ что нужно в рекордсет, и искать уже по нему при помощи Find / Filter.
Пробовал?
2. ...Этот вариант, конечно, нехило жрёт память.. Но тормоза при работе с файловой бд мы в своё время победили только таким образом.

1. Find Ни разу не пробовал. Обязательно проверю.
2. Пусть жрет! Не страшно! Тоже попробую!

Спасибо за подсказки!

[Andrey Fedorov]

1. Find Ни разу не пробовал. Обязательно проверю.

Вытаскиваешь в статический клиентский Recordset, индексируешь поле по которому ищешь:

Код: Выделить всё

r!ФИО.Properties!Optimize = True

Ну и далее Find

2. Пусть жрет! Не страшно! Тоже попробую!

Сколько записей-то в таблице? Вроде у тебя в любом варианте тормозов не должно быть...

[SergT]

Записей 20 000-30 000 - влезет! Спасибо! Буду пробовать!