Можно (и лучше) использовать сохраненые параметрические запросы вместо Filter (хотя, если учесть, что курсор клиентский, т.б. записи кешированны на клиенте (не совсем точное отличие курсора клиентского, но сойдет), то метод Filter должен работать достаточно шустро.
Но влюбом случае DennisS'у нужно поподробнее расказать про задачу и вслать кусок кода, который более всего тормозит прогу.

Все-таки вышли куски кода, а то гадаем на кофейной гуще.
Раскажи про то, где у тебя стоят индексы?
БД на чем?
Сжимаешь?
ADO какое?
Какой типа рекордсета открыт?
Почему переходишь на Find, а не на Seek?
TreeView заполняешь сразу или только Родителей, а Children в момент обращения?

P.S.
Поиск по 3000 записям даже с условием Like "*" & Что-то "*" не должен особо тормозить, да и 13 Мб многовато (хотя м.б. полей много)
Так что давай все поподробнее
P.S.S.
Быстродействие мерь функцией
Public Declare Function timeGetTime Lib "winmm.dll" () As Long
И прийдется делать это ручками :-(

>- БД на чем?
>Access 2000 база.
Поставь сервис-паки (№3)

- Сжимаешь?
Нет. Это не снизит быстродействие?
Увеличит, если повезет, то сжатие решит твои проблемы

>- ADO какое?
>2.6
Ставь SP или 2.7 и опять SP

>- Какой типа рекордсета открыт?
>Я рекордсет открыл один раз и потом его гоняю. Тип Dynamic.
Открой ...adOpenForwardOnly, adLockReadOnly
Однонаправленный, только чтение, т.е. самый быстрый

>- Почему переходишь на Find, а не на Seek?
>Хммм... А какая разница? Seek быстрее? Если да, то откуда знаете. Я тоже >хочу об этом почитать.
Разница прямо скажу больша. Как между запорожцем и Мерседесом
А прочитать об этом можно в Хелпе
...Searches the index of a Recordset to quickly locate the row that matches the specified values, and changes the current row position to that row.
Особо обрати на строчку ...quickly ...

>reeView заполняешь сразу или только Родителей, а Children в момент >бращения?
>Я заполняю полностью. Но, наверное, думаю сделаю так, чтобы Childrenы >заполнялись в момент открытия ветки.
Будет шустрее